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.
On Wed, Jun 17, 2009 at 6:37 PM, Stefan Haustein <haust...@google.com>wrote:
> On Tue, Jun 16, 2009 at 12:54 AM, Stefan Haustein <haust...@google.com>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 <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
>>
>>
>
>
> --
> 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
-~----------~----~----~----~------~----~------~--~---
