On Dec 27, 9:46 am, Attila Szegedi <[EMAIL PROTECTED]> wrote:
> I have a custom wrap factory that wraps java.util.List instances into
> a Scriptable that allows access by index, i.e. "list[1]". It
> implements getIds() method appropriately to return an array of
> integers for the list, providing the usual semantics where you can
> then iterate over the list as you could over a native array:
>
> for(i in list) { doSomethingWith(list[i]); }
>
> This worked until recently. Now, Rhino will ignore getIds() if the
> wrapped object implements java.lang.Iterable, and for..in will iterate
> over values:
>
> for(i in x) { java.lang.System.out.println(i); }
>
> when "x" is a java.util.List will print the values, and will no longer
> print indices.
>
> Shouldn't getIds() still have priority? Also, what'd be the easiest
> way to restore the original behaviour in my custom wrappers? Also, is
> the new behaviour desirable at all? I.e. a for..in over a native Java
> array will keep iterating over the indices, as it always did, which
> creates a bit of inconsistency.
>
> So, while we're at that, shouldn't we allow java.util.List instances
> to be treated identically to native Java arrays, similar to
> NativeJavaArray class? I know List is a Java 2 interface, and thus
> didn't exist back when Rhino (and LiveConnect) were originally
> created, but I think we should catch up with times...
>
> Attila.In general I'm pretty hesitant to change behavior in Rhino that affects backwards compatibility. My thinking in making the change to the way Interables are handled was that I figured people weren't too dependent on the previous behavior of iterating over the method properties of an Iterable because it's of limited usefulness. However, I didn't think of your case of a custom wrap factory. Thanks for pointing this case out--I agree that this is not a good change to make as is. Perhaps we need some new top-level functions that can take Java Iterables and make them JavaScript iterators, Java Lists and make them JavaScript Arrays, and Java Maps and make them JavaScript "hashes". Then the change is under the control of the script writer and avoids problems with backwards compatibility. Thoughts? --Norris _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
