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 <sco...@google.com> 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, <cromwell...@google.com> 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
