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 <cromwell...@gmail.com> 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<cromwell...@gmail.com>
> 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<haust...@google.com>
> wrote:
> >> +1 Ray
> >> Could you contribute your implementation(s)?
> >>
> >> On Thu, Jun 11, 2009 at 12:51 PM, Joel Webber <j...@google.com> 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 <cromwell...@gmail.com>
> >>> 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<sp...@google.com> 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
-~----------~----~----~----~------~----~------~--~---
