Since I was doing non-standard things, I don't really want to look backwards to see what Rhino 1.6 was doing. Instead just move forward to fixing my code. What do I do with the boolean __iterator__ is called with? Does that determine if the function returns ids or values? Thanks much Kevin
________________________________ From: Norris Boyd [mailto:[EMAIL PROTECTED] Sent: Mon 3/3/2008 4:17 PM To: Ruland Kevin-BHP637 Cc: [email protected] Subject: Re: How does iterable work in 1.7? On Mon, Mar 3, 2008 at 4:09 PM, Ruland Kevin-BHP637 <[EMAIL PROTECTED]> wrote: Norris, In ScriptRuntime rev 1.290.2.2 (latest on Rhino1_7R1_BRANCH), The enumNext method contains at line 1997 : int intId = ((Number)id).intValue(). This is in an else block where it had tested if the id was a String. This is the block of code: if (id instanceof String) { String strId = (String)id; if (!x.obj.has(strId, x.obj)) continue; // must have been deleted x.currentId = strId; } else { int intId = ((Number)id).intValue(); if (!x.obj.has(intId, x.obj)) continue; // must have been deleted x.currentId = x.enumNumbers ? (Object) (new Integer(intId)) : String.valueOf(intId); } I end up with a class cast exception because my id object is actually a Scriptable (not a String nor Number) Odd, that code has been unchanged since 2003. Not sure how else it could be called such that it would get the ClassCastException that it didn't before. I do suspect that to make Rhino compatible with my code, quite a bit would need to be changed within the new iteration code. Even if the cast were tested first, I would then end up with problems in enumId or enumValue. As I said, I think I had been abusing Rhino and probably implemented a non-ECMA compliant object because getIds() did not return an array of strings or numbers. Looking at ECMA 262, it seems that for in should operate on "names". Really, I would like to understand what I need to do to get my objects compatible with the new __iterator__ construct. If I change them, the we can iterate over values or names without having to have two different methods. So what do I need to have __iterator__ do? It looks like some kind of callable which gets invoked with a boolean argument. What does it need to return after being called? It should return an iterator, which is an object that has a next method that either returns the next element of the iteration or throws StopIteration. Kinda a pain to code in Java, as you'll have to look up the StopIteration value in the current scope. Kevin ________________________________ From: [EMAIL PROTECTED] on behalf of Norris Boyd Sent: Mon 3/3/2008 1:29 PM To: [email protected] Subject: Re: How does iterable work in 1.7? On Mar 3, 1:09 pm, "Ruland Kevin-BHP637" <[EMAIL PROTECTED]> wrote: > I recall that thread and thought by the last comment by Norris, that the previous behavior was restored. Alas, I should have written more test cases before committing to 1.7. > > I think my problem is slightly different in that my getIds() was not returning "identifiers" but rather values. That is the array contained neither Strings nor Numbers but rather other ScriptableObjects. It seemed that your problem was your object implemented the Java Iterable interface and the ScriptableRuntime.enumInit method decided not to call getIds(). (I haven't checked the cvs log to verify this). > > My fix will probably to remove my creative abuse of the getIds() method and instead implement __iterator__ property. > > Kevin > > ________________________________ > > From: Attila Szegedi [mailto:[EMAIL PROTECTED] > Sent: Mon 3/3/2008 11:47 AM > To: Ruland Kevin-BHP637 > Cc: [EMAIL PROTECTED] > Subject: Re: How does iterable work in 1.7? > > Actually, I raised this myself about two months ago: > > <http://groups.google.com/group/mozilla.dev.tech.js-engine.rhino/brows... > > > > Nothing has been done about it yet. That's actually quite a serious > problem for me, but just as you, I'd be willing to adapt if I knew how > -- we'd need more input from whoever wrote the new Iterable support > (either Norris or someone he committed the code on behalf of). > > Attila. > > On 2008.03.03., at 18:13, Ruland Kevin-BHP637 wrote: > > > Hi all, > > > Some of my custom ScriptableObject implementations have broken > > between 1.6 and 1.7. I had been abusing getIds() to return non- > > String, non-Number objects (basically value references) to implement > > crude 'for each' value-iteration semantics. What I had done is now > > completely broken when using 1.7 because ScriptRuntime.enumNext now > > does a blind cast to Number. > > > I am willing to change my code to make this work correctly, but I'd > > like some idea about what I need to do. Is there any documentation > > on the implementation of iteration in 1.7? > > > Thanks > > > Kevin Where does Rhino do its blind cast to Number that causes you problems? --N _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
