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 -~----------~----~----~----~------~----~------~--~---
