Subj : Re: Fwd: Rhino, Changes to JavaMembers.java To : netscape.public.mozilla.jseng From : =?ISO-8859-1?Q?J=FCrg_Lehni?= Date : Thu Feb 17 2005 03:38 pm On 2005-02-16 10:39:01 +0100, Igor Bukanov said: > You can either send the patch to the newsgroup (I cross-post the mail > there) or file an enhancement bug at bugzilla.mozilla.org against > Rhino. And please use patches, not the files itself, as it is easier to > see what happens. Ok, so should I submit again, as a patch? And what do you think of the proposed changes? > The problem is that any optimization-only changes to Scriptable > interface or any other public API in Rhino are hard to justify as it > would break too many existing embeddings. To demonstrate how bad the > situation could be consider the change in the debug implementation > internals that was done in Rhino 1.5R4 in 2002. That change made Rhino > incompatible with BSF library which explicitly depended on the modified > classes. Since BSF is used in many projects from apache.org and since > the last public release of the library was at the end of 2002, many > people are still forced to use 1.5R3 release of Rhino. I see. But as getIds() would be kept, I cannot see how this would break anything at all. I don't know how big the speed gain would be, but to me it seems a bit crazy to create an array containing all indexes of the array to be enumerated just to walk through its elements. While i really like the "for (i in array)" syntax, the fact that Rhino handles it in that way makes it very slow compared to "for (var i = 0; i < array.length; i++)" for huge arrays... I just thought that would be an easy to implement modification that wouldn't really harm any project depending on this. It could be done by creating a new interface called 'enumeratable', and if the class implements this, the new mechanism is used. If it's not there, the fallback scenario is using getIds() just like it was done until now. I could even work on this myself if you think this makes sense. Regards, Jürg .