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
>
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
