Re: Implementing NodeList

Thanks. At least I know I'm not missing anything too obvious.

>we disagree.  It makes a lot of sense for scripting crowd however.

That's often the nature of the beast: The more details you hide from the
user, the more of a pain it tends to be for the implementer.


But I agree this may be going "above and beyond the call of sanity".
Standard iterator design is a snapshot partly because it's easier to
implement.. but also because the "live" version yields some behaviors which
users find confusing.

For example: If I'm iterating through the NodeList, and in response to
processing a node I find I have to insert structure earlier in the DOM,
that's going to blow my iteration loop out of the water -- the indices
shift, and I'll wind up re-processing earlier nodes -- unless I add code to
search forward in the NodeList to re-establish my position. Conversely, if
I delete an earlier node I may skip processing something unless I search
back. Either can be solved by processing into a second tree, I suppose...
but if you weren't updating the source tree, the NodeList wouldn't have to
be live.

That wouldn't be a problem if we were using "next()" to sequence through
the NodeList... but we've tied ourselves to indices.

But if you tell me that script writers want it to work this way, I'll take
your word for it; you've been looking at this much longer than I.

Received on Monday, 27 July 1998 09:08:33 UTC