Sounds good. Now that I think about it, it may not make much performance difference if time tends to be dominated by the actual math ops, but I suppose every bit helps?
On Tue, Mar 29, 2011 at 10:35 AM, Daniel Rice (דניאל רייס) <[email protected]>wrote: > I did the reimplementation. Being less familiar with the intricacies of > JavaScript, it seems likely that I missed an opportunity to preserve the > nativeness of the array. I'd be happy to take a look at this after the 2.3 > release. > > On Mon, Mar 28, 2011 at 5:52 PM, Scott Blum <[email protected]> wrote: > >> Something smells fishy here. I'm quite certain that this used to be >> implemented strictly as a two-double array in web mode, a true array. At >> some point it was modified to use 3 elements instead of 2, but I don't think >> it should have lost its nativity. >> >> >> On Mon, Mar 28, 2011 at 5:36 PM, <[email protected]> wrote: >> >>> >>> >>> http://gwt-code-reviews.appspot.com/1389803/diff/1/dev/core/super/com/google/gwt/lang/LongLibBase.java >>> File dev/core/super/com/google/gwt/lang/LongLibBase.java (right): >>> >>> >>> http://gwt-code-reviews.appspot.com/1389803/diff/1/dev/core/super/com/google/gwt/lang/LongLibBase.java#newcode325 >>> dev/core/super/com/google/gwt/lang/LongLibBase.java:325: _.l = l, _.m = >>> m, _.h = h, _); >>> On 2011/03/28 21:31:25, scottb wrote: >>> >>>> Stupid question, but why can't we just return {l:l, m:m, h:h}? >>>> >>> >>> Good question. It looks like LongEmul is not a JSO, because they want to >>> reuse it in both JVM and ProdMode, so it's a Java type. This code may >>> have existed before @GwtScriptOnly or SingleJsoImpl. If I were during >>> this today, I'd make LongEmul an interface, use JSO for ProdMode, and >>> JRE impl for everything else. >>> >>> I guess we'll revisit it later. >>> >>> >>> http://gwt-code-reviews.appspot.com/1389803/ >>> >> >> -- >> http://groups.google.com/group/Google-Web-Toolkit-Contributors >> > > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
