On 31 mar, 22:29, Ray Cromwell <[email protected]> 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)
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---

Reply via email to