I do as well - I'm mmastrac. On 15-Jun-09, at 8:02 PM, Ray Cromwell wrote:
> > I do, cromwellian is my id on the sandbox. > > -Ray > > > On Mon, Jun 15, 2009 at 6:14 PM, Bruce Johnson<[email protected]> > wrote: >> I'm starting to make a bit o' progress on this. I'll send out a >> design doc >> "real soon now". >> >> BTW, anyone on the Contributors list here have Wave sandbox >> accounts? Sure >> would be easier to discuss this in a wave... >> >> On Mon, Jun 15, 2009 at 7:54 PM, Stefan Haustein >> <[email protected]> >> wrote: >>> >>> Ray, >>> >>> I think we can improve the class over time -- any reasonable >>> starting >>> point (even without iterators or with non-optimal iterators) would >>> help >>> significantly. >>> >>> Stefan >>> >>> On Sat, Jun 13, 2009 at 4:21 AM, Ray Cromwell >>> <[email protected]> >>> wrote: >>>> >>>> BTW, the last proposal is very unsafe with some form of escape >>>> analysis since it is unsafe to pass references to classes which >>>> reference local scope to other scopes. Another possibility is a >>>> form >>>> of 'destructuring' of Iterator classes by inlining them completely >>>> into local scope vs escape analysis and then forgoing separate >>>> construction. >>>> >>>> A simpler way to maintain for-each with JRE collections without >>>> creating objects is to change the way that for-each deals with >>>> Iterable<T> when T is a List. >>>> >>>> The compiler could change: >>>> for(T x : foo) { ... } >>>> >>>> where foo is a List<T> >>>> >>>> into >>>> >>>> for(int i=0; i<foo.size(); ++i) { >>>> T x = foo.get(i); >>>> } >>>> >>>> instead of calling foo.iterator() and using Iterator methods. >>>> >>>> -Ray >>>> >>>> On Fri, Jun 12, 2009 at 7:31 PM, Ray >>>> Cromwell<[email protected]> >>>> wrote: >>>>> I'm in the process of some final tweaks on GQuery, so I'll look >>>>> at how >>>>> much of my private JSArray class I can move over as a patch. >>>>> >>>>> One possibility for avoiding Iterator object creation without >>>>> using >>>>> flyweights is to introduce a new Iterator type which contains >>>>> methods >>>>> which are parameterized by the collection and which use my >>>>> Extension >>>>> Method/Category method JSO trick. >>>>> >>>>> public class FastIterator<T> extends JavaScriptObject { >>>>> protected FastIterator() {} >>>>> public <S, T extends List<S>> FastIterator<S> make(T<S> list) { >>>>> return (FastIterator<S>)(GWT.isScript() ? makeWeb() : >>>>> makeHosted()); >>>>> } >>>>> >>>>> private final native FastIterator makeWeb() /*-{ >>>>> return 0; >>>>> }-*/; >>>>> >>>>> private final native FastIterator makeHosted() /*-{ >>>>> return [0]; >>>>> }-*/; >>>>> >>>>> public final int value() { >>>>> return GWT.isScript() ? valueWeb() : valueHosted(); >>>>> } >>>>> >>>>> public native int valueWeb() /*-{ >>>>> return this; >>>>> }-*/; >>>>> >>>>> public native int valueHosted() /*-{ >>>>> return this[0]; >>>>> }-*/; >>>>> >>>>> public native hasNext(List<T> list) { >>>>> return value() < list.size(); >>>>> } >>>>> >>>>> public native T next(List<T> list) { >>>>> return list.get(value()++); // unsure if using value() as >>>>> rvalue >>>>> will work here >>>>> } >>>>> } >>>>> >>>>> then you should be able to write code like >>>>> >>>>> List<String> foo = getList(); >>>>> FastIterator<String> iter = FastIterator.make(foo); >>>>> >>>>> while(iter.hasNext(foo)) { >>>>> String s = iter.next(foo); >>>>> } >>>>> >>>>> Why doesn't this create any additional objects? Because >>>>> 'iter'/FastIterator is actually a native JS number/scalar type, >>>>> and >>>>> what this is really doing is simulating the addition of >>>>> hasNext()/next() to the number's prototype. >>>>> >>>>> We could dispense with the need for an additional parameter if >>>>> GWT had >>>>> a magic method for allocating new local variables/symbols in the >>>>> local >>>>> scope. Imagine if writing >>>>> >>>>> Variable<T> x = GWT.createVariable(0); >>>>> >>>>> was a magic method that just generated a 'var x = 0' >>>>> declaration, only >>>>> it promised to always be inlined and do so in the caller's scope. >>>>> 'Variable' would be a magic class that never creates fields on the >>>>> actual object themselves and are pruned/removed at runtime. >>>>> >>>>> Then you could have FastIterator impersonate a reference to the >>>>> underlying List<T>, and rewrite hasNext()/next() as: >>>>> >>>>> VariableInt x = GWT.createVariableInt(0); >>>>> public boolean hasNext() { >>>>> return x.get() < this.size(); >>>>> } >>>>> >>>>> public T next() { >>>>> return this.get(x.get()++); // or x.postIncrement() >>>>> } >>>>> >>>>> this would produce code that would create no additional objects as >>>>> well as maintain Iterator-like interface. >>>>> >>>>> -Ray >>>>> >>>>> >>>>> On Thu, Jun 11, 2009 at 7:25 AM, Stefan Haustein<[email protected] >>>>> > >>>>> wrote: >>>>>> +1 Ray >>>>>> Could you contribute your implementation(s)? >>>>>> >>>>>> On Thu, Jun 11, 2009 at 12:51 PM, Joel Webber <[email protected]> >>>>>> wrote: >>>>>>> >>>>>>> +1 Ray. Now here's the really tricky question. Is there any >>>>>>> way we >>>>>>> can >>>>>>> take advantage of Javascript's "for (x in y) { ... }" syntax >>>>>>> (and >>>>>>> should we, >>>>>>> given its spotty performance)? My intuition tells me that the >>>>>>> only >>>>>>> way we >>>>>>> could use it would be through a callback, because there's >>>>>>> nothing >>>>>>> like .NET >>>>>>> generators/yield in Javascript. >>>>>>> On Wed, Jun 10, 2009 at 7:26 PM, Ray Cromwell <[email protected] >>>>>>> > >>>>>>> wrote: >>>>>>>> >>>>>>>> My take on this is that there is many places where I'd like >>>>>>>> to avoid >>>>>>>> JRE collections, but the basic JsArray is too much of a >>>>>>>> downgrade. I >>>>>>>> don't mind changing it to <T> if it doesn't effect >>>>>>>> performance cause >>>>>>>> then I could subclass it, but as an example of the stuff I >>>>>>>> would >>>>>>>> like >>>>>>>> in a 'FastArrayList' that is not a collections derivative: >>>>>>>> >>>>>>>> 1) add() instead of just set(length(), item) (e.g. push) >>>>>>>> 2) addAll(anotherFastArrayList) (e.g. concat) >>>>>>>> 3) splice >>>>>>>> 4) toArray() (webmode is reinterpret cast op) >>>>>>>> 5) remove >>>>>>>> 6) shift/unshift (useful for queue when combined with pop) >>>>>>>> >>>>>>>> I use the following pattern all over GQuery to avoid JRE >>>>>>>> collections >>>>>>>> but preserve for-each >>>>>>>> >>>>>>>> for(Foo f : fooList.elements()) { ... } >>>>>>>> >>>>>>>> where fooList is my own JsArray<T> class, and elements() >>>>>>>> returns T[] >>>>>>>> via reinterpret cast in webmode. >>>>>>>> >>>>>>>> -Ray >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jun 11, 2009 at 2:43 AM, Lex Spoon<[email protected]> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Bah, mis-send. What I was typing was: >>>>>>>>> >>>>>>>>> >>>>>>>>>> I though the point was to get rid of JRE collections? >>>>>>>>>> Anyway, >>>>>>>>>> the >>>>>>>>>> collection in question is used as a queue. I would hate to >>>>>>>>>> see >>>>>>>>>> its >>>>>>>>>> performance get worse when there' >>>>>>>>> >>>>>>>>> ...when there's a known, straightforward alternative, and when >>>>>>>>> that >>>>>>>>> alternative provides a class people have been wanting for >>>>>>>>> separate >>>>>>>>> purposes. >>>>>>>>> >>>>>>>>> >>>>>>>>> Lex >>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Stefan Haustein >>>>>> Google UK Limited >>>>>> >>>>>> Registered Office: Belgrave House, 76 Buckingham Palace Road, >>>>>> London >>>>>> SW1W >>>>>> 9TQ; Registered in England Number: 3977902 >>>>>> >>>>>> >>>>> >>> >>> >>> >>> -- >>> Stefan Haustein >>> Google UK Limited >>> >>> Registered Office: Belgrave House, 76 Buckingham Palace Road, >>> London SW1W >>> 9TQ; Registered in England Number: 3977902 >>> >> >> > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
