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