Changes between Version 148 and Version 149 of j2p
- Timestamp:
- 10/17/24 10:01:21 (2 weeks ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
j2p
v148 v149 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. 137 137 138 139 138 140 === Auto Boxing 139 141 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. 140 142 141 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 142 143 {{{ 144 boolean b=false; 145 List<Boolean> l=new ArrayList<>(); 146 l.add(b); 147 }}} 148 149 Here in line 3 the b is auto-boxed from boolean to Boolean. 150 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. 151 152 But keep reading, the automatic casting is closely related and is more problematic. 153 154 === Implicit casting, narrowing 155 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. 156 157 The translator does recognise differences between left and right side in assignments and tries to cast properly. Eg, 158 {{{ 159 Float x=3 160 }}} 161 162 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 163 {{{ 164 x:float=3 165 }}} 166 167 but it would be wrong as x now will contain an int (regardless of the type hint). 168 169 A more tricky case is this 170 {{{ 171 Float f = Float.valueOf(3); 172 }}} 173 174 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. 175 176 Another example: 143 177 {{{ 144 178 int n=1; … … 146 180 }}} 147 181 148 You will have to call an explicit converter, typically toString(), on the arguments that need to be converted into the proper argument type. 182 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 183 {{{ 184 return "number "+ ((Integer)n).toString(); 185 }}} 149 186 150 187 … … 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. 170 207 171 === Implicit casting, narrowing172 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.173 208 174 209 === @NonNull