It could be conditioned on jsinterop being switched on or not, in general though, more and more compiler switch modes I think encourage lazy/bad code practices in the ecosystem.
Better would be a "lint"/"checked mode" that throws hard errors in your app when you do something that violates the assumptions, like thinking there's a way to tell if something is a float vs a double. On Fri, Nov 21, 2014 at 11:53 AM, Goktug Gokdogan <gok...@google.com> wrote: > The one of the problems is the boxing makes the support of method > overloading, var args, etc. more complicated and much slower in JsInterop. > Making it optional is not going to help with those. > I think with the experiment we will have a very good data on the impact of > this change, after that we can make a much better educated decision. If the > impact is significant then like you said we can look for other options like > making it optional. > > On Fri, Nov 21, 2014 at 2:57 AM, Arnaud TOURNIER <ltea...@gmail.com> wrote: >> >> Can that be an option ? So that the user knows what happens consciously, >> in order to optimize the runtime. I admit, that this would not simplify the >> jscompiler base code, but would provide the user with another powerful >> optimization... >> Just an idea... >> >> Thanks >> Arnaud >> >> Le vendredi 21 novembre 2014 02:41:42 UTC+1, Goktug Gokdogan a écrit : >>> >>> Resurrecting this. >>> >>> I talked with Roberto and then Ray yesterday and we think that this is a >>> good idea and this will both improve performance and simplify >>> jsinterop/compiler. >>> >>> The general idea is to make the boxed types work similar to String so all >>> instance methods will be staticified and instanceof operations will work >>> like typeof x === 'number'. There are other issues we need to solve as well >>> but it looks feasible. >>> >>> The main drawback is; when somebody does something like list.get(x), if >>> the returned value is number, it will return true to both instanceof Double >>> and instanceof Integer etc. >>> In practice we don't believe this is going to be an issue and our >>> numerical emulation of java is already has other gotchas. >>> >>> Ray volunteered to provide us a patch to analyze the impact in google3 >>> and we will go from there. >>> >>> Let me know what you think. >>> >>> >>> >>> >>> >>> >>> On Sat, Aug 3, 2013 at 7:05 PM, Goktug Gokdogan <gok...@google.com> >>> wrote: >>>> >>>> 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 <cromw...@google.com> >>>> 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 <gok...@google.com> >>>>> 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? >>>>> >>>>> >>>> >>> >> -- >> 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/google-web-toolkit-contributors/ad2ff664-cde8-45d8-b7da-a75dc677aeba%40googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7chxftvAP6TX_SngxvXHM%3D2PU7B1rQc9kaFkK-wzjMBeA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
