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.
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
