Changes between Version 148 and Version 149 of j2p

Timestamp:

10/17/24 10:01:21 (6 weeks ago)

Author:

wouter

Comment:

--

j2p

@@ -136 +136 @@
 This approach ignores the more recent Python Enum class. This new approach is incompatible with the traditional approach, it gives an extra layer of indirection, it does not allow the custom constructors that we need, it is very complex, and all this complicates our translation job. 
 
+
+
 === Auto Boxing
 Autoboxing is the automatic conversion that the Java compiler makes between the primitive types and their corresponding object wrapper classes. For example, converting an int to an Integer, a double to a Double, and so on. If the conversion goes the other way, this is called unboxing.
 
-The translator currently does not support auto boxing. That means you will get an error on the python side if you for instance do this on the java side
-
+{{{
+boolean b=false;
+List<Boolean> l=new ArrayList<>();
+l.add(b);
+}}}
+
+Here in line 3 the b is auto-boxed from boolean to Boolean.
+In many cases, this is no problem, because python has no equivalent objects for primitive types, so there are no 2 variants of boolean, float, str. So both int and Integer are translated to python int anyway.
+
+But keep reading, the automatic casting is closely related and is more problematic.
+
+=== Implicit casting, narrowing
+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
+{{{
+x:float=3
+}}}
+
+but it would be wrong as x now will contain an int (regardless of the type hint).
+
+A more tricky case is this
+{{{
+Float f = Float.valueOf(3);
+}}}
+
+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.
+
+Another example:
 {{{
 int n=1;
@@ -146 +180 @@
 }}}
 
-You will have to call an explicit converter, typically toString(), on the arguments that need to be converted into the proper argument type.
+Java will automatically (1) convert n to Integer (2) call toString. Currently, in this special case (+ operator) the translator does not support either, so you will have to do both yourself. eg write in java
+{{{
+return "number "+ ((Integer)n).toString();
+}}}
 
 
@@ -169 +206 @@
 All these complications around varargs, including more eg [https://github.com/mrocklin/multipledispatch/issues/72 around dispatching vararg-typed methods] led us to currently not support varargs.
 
-=== Implicit casting, narrowing
-Java does automatic casting to silently convert between bytes, int, long etc. These can also involve narrowing, 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.
 
 === @NonNull