On Thu, Jun 18, 2009 at 12:02 AM, Bruce Johnson <[email protected]> wrote:
> Stefan, if it's really urgent, I would suggest just forking JsArray into > your own project packages for a while. They're simple enough that it won't > be much trouble to unfork when something better comes along -- the > collections I have in mind for core GWT are a little more ambitious, and so > they will inevtiably take longer than you'll want to wait. Our main problem is code size, so "ambitious" scares me :) The actual problem at hand is that GWT runasync stuff drags in LinkedList which is used nowhere else, so having our own copy of JsArray in our project won't really help (And my CL for replacing Hashtable with our own JsStringMap slowly deteriorates because I realized that Hashtable is used in GWT internally in libraries we cannot replace easily). Why not release early and start with a basic copy of JsArray and then add more functionality (e.g. iterable) later? Stefan > On Wed, Jun 17, 2009 at 6:37 PM, Stefan Haustein <[email protected]>wrote: > >> On Tue, Jun 16, 2009 at 12:54 AM, 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. >> >> >> Ray, >> >> I am blocking on this for other size optimizations. Do you know when you >> would have some kind of starting point ready to submit? >> >> If it is still a while away, I'd like to move ahead with a copy of JsArray >> that is not limited to JSO content. >> >> Stefan >> >>> >>> >>> 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 >>> >>> >> >> >> -- >> 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 -~----------~----~----~----~------~----~------~--~---
