Changes between Version 149 and Version 150 of j2p

Timestamp:

10/17/24 10:08:54 (2 weeks ago)

Author:

wouter

Comment:

--

j2p

@@ -152 +152 @@
 But keep reading, the automatic casting is closely related and is more problematic.
 
-=== Implicit casting, narrowing
+=== Casting
+Translation of explicit casting has resonable support. Eg if you write 
+{{{
+long x=(long)3;
+}}}
+then the translator will convert the int to long. 
+
 Java does automatic casting to silently convert between bytes, int, long etc. These can involve narrowing, widening, and potentially lead to conversions or loss of precision etc. There is partial support for these. The translator recognises when such conversion is done and tries to insert extra code to implement the expected narrowing as needed. But the specification has lots of special cases and the implementation is partial.
 
 The translator does recognise differences between left and right side in assignments and tries to cast properly. Eg,
 {{{
-Float x=3
-}}}
-
-it will recognise the right side of the assignment is an int, and convert it to float before assigning into the x. Note that python itself will not give any warning on type errors, this would be fine in python
+float x=3;
+}}}
+
+it will recognise the right side of the assignment is an int, and convert it to float before assigning into the x. Note that python itself will not give any warning on type errors, this would be fine in python:
 {{{
 x:float=3
@@ -172 +178 @@
 }}}
 
-The call argument, an integer, is in java automatically cast to a float, because that's the actual type required by valueOf. The translator currently does not recognise this case.
+The call argument, an integer, is in java automatically cast to a float, because that's the actual type required by valueOf. The translator currently does not recognise this case and this call would pass an integer into the call.
 
 Another example: