On Tue, Mar 31, 2009 at 6:42 PM, Freeland Abbott <fabb...@google.com> wrote:

> The for (T x: array) ... use case is precisely what's motivating me, yes; I
> don't have any intention of e.g. implementing Iterator.remove().  We allow
> that syntax on "real" Java arrays, but not on JsArrays.
>
> Does returning T[] actually avoid creating an Iterator object, or does it
> just create an Iterator of different type?
>
> I'm not sure I understand Ray's concern... JSO wouldn't implement iterable,
> so another subclass of JSO would do whatever the author made it do.  Most of
> the methods on JsArray<T> and e.g. JsArrayString[1] are final, but we
> wouldn't *have* to do that for iterator(), so a subclass could still
> override.
>
>
>
> [1] why don't we just use JsArray<String> instead of JsArrayString?
> Pre-generics compatibility?  If so, should we re-implement JsArrayString as
> a trivial extension of JsArray<String>


I believe this is because String is not a subclass of JavaScriptObject.
 It's not just a matter of changing the generic declaration of JsArray,
because passing JSO's is different between from passing Strings in JSNI
(hosted mode will barf.)


>
>
>
>
> On Wed, Apr 1, 2009 at 9:22 AM, Thomas Broyer <t.bro...@gmail.com> wrote:
>
>>
>>
>>
>> On 31 mar, 22:29, Ray Cromwell <cromwell...@gmail.com> wrote:
>> > Wouldn't this cause a problem when you want more than one JSO to
>> implement
>> > Iterable? I wouldn't make the class itself implement Iterable, I'd add a
>> > helper method to return an Iterable, e.g.
>> > public class JsArray<T> extends JavaScriptObject {
>> >
>> >    public Iterable<T> iterable() { ... }
>> >
>> > }
>> >
>> > for(T foo : someJsArray.iterable()) {
>> >
>> > }
>> >
>> > The risk of adding it to the class type itself is that you potentially
>> block
>> > anyone else from making a JSO that implements Iterable.
>>
>> For better performance in web mode, returning a T[] would be
>> preferable (as it would just return the JsArray unchanged, without
>> wrapping class).
>> See
>> http://code.google.com/p/gwt-in-the-air/source/browse/trunk/src/net/ltgt/gwt/jscollections/client/JsArrays.java#124
>> (that's something we discussed already a few months ago and I believe
>> that's what you're using in GQuery too; the array should be considered
>> read-only, the main use case is iterating using a for(:) loop)
>>
>> Or maybe, i don't if it would work: can a super-source class
>> implementation return a different type as a "normal" source class?
>> i.e. in src/com/google/gwt/core/client/JsArray<T>: Iterable<T> iterable
>> ()
>> while in super/com/google/gwt/core/client/JsArray<T>: T[] iterable()
>> though it can break at compile time if not used in a for(:) loop (e.g.
>> assigned to an intermediate Iterable<T> variable and/or explicitly
>> calling Iterable<T> methods)
>>
>>
>
> >
>


-- 
Eric Z. Ayers - GWT Team - Atlanta, GA USA
http://code.google.com/webtoolkit/

--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---

Reply via email to