I know this is something beyond interop stuff. However, in general I don't like the idea of autoboxing being a concern in shaping of any APIs so it started to keep bugging me since our discussion.
I know this will sound controversial but I really wonder if most applications would care if boxed type of Integer and Double were actually act like the same class. (i.e. instanceOf Integer and instanceOf Double both will return true to same object. So equals will return true when the values are equal even boxing types are different) Also current implementations of compareTo, toString, hashcode are all compatible so those shouldn't be ok. I think this can be a good candidate for an opt-in kind of optimization in compiler. We can quickly experiment with it in Google3 by changing the behavior of equals and instanceof and then see which projects survive :) Another option is making this change just for Double (i.e. let the Double own Number.prototype). Then anybody who wants numeric performance then can stick with double and safely put into lists, maps, use it in loops without any concerns. I also wonder if we would have better performance if we were to use js boxing type (ie. new Number(100)) as the boxing type? Perhaps JS VMs perform better if they do the unboxing themselves? On Fri, Aug 2, 2013 at 1:33 AM, Ray Cromwell <[email protected]> wrote: > I explored that a long time ago when Lightweight Collections were > proposed, but it won't work that simply. (Sadly, most of the original > discussions on this with the Atlanta team were in Google Wave and forever > lost) The reason why it won't work is that there is no way to tell the > difference between Integer and Double, Float, Byte, Short, et al. > > Only one boxed type can "own" Number.prototype, so instanceof and equals() > checks will fail. Also, toString() and compareTo() might return values that > break existing apps. > > It is impossible to write a runtime test on a primitive JS number that can > distinguish between a Double and a Float, and it is impossible to store a > castable type map on a given instance of number. > > The only way to make this work would be to ensure that *all such* JS > numbers are boxed. > > This won't work: > var x = 42.3; > x.isFloat = true; > > This also won't work > > var x = Number(42.3); > x.isFloat = true; > > because typeof(x) == "number" > > This will work > var x = Object(42.3) > x.isFloat = true; > > x + 2 => prints 44.3 > x.isFloat => prints true > > But this is nothing more than making a JSO that holds the number with > extra runtime fields. > > Leaving all this aside, I don't understand why you're trying to do this in > the first place. Java is a language which insists on a difference between > the semantics of primitive value types and class based reference types. > This will most definitely break DevMode. For interop purposes, just > declaring the right return type is better IMHO. If you were to write a game > using WebGL that had all the interfaces using boxed types, it would be > horrendous performance wise. > > Eliminating autoboxing via a hack like this might be plausible, but I > think it should be separate from the interop stuff. It's an optimization > that has impacts far and wide. > > -Ray > > > > On Thu, Aug 1, 2013 at 6:01 PM, Goktug Gokdogan <[email protected]> wrote: > >> I was thinking about autoboxing of numbers when assigned to Object and I >> started to question if we really need them in Java to JS translation - at >> least for a subset (i.e. Integer and Double). >> >> Object has only a few methods that we can put into Number.prototype (like >> we do for String) and all methods to Integer/Double can be converted to >> static calls then theoretically we can drop most of the java autoboxing >> code. We can also find similar solutions to calls over java.lang.Number. >> >> Perhaps, I'm missing some corner cases but I really feel like we can find >> a way to get rid of them at least for the most scenarios. Am I being too >> naive on this? >> > > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
