My own reasoning and two questions:
Stephen R. Savitzky wrote:
> Miles Sabin <msabin@cromwellmedia.co.uk> writes:
>
> That was me. I agree with you: I'd really prefer simple O(1) iterators with
> no implementation impact and easily-documented conditions under which their
> behavior is undefined.
"Robustness" is a relative term, anyway. But we have had lots of people that
seem to think they will be severely disadvantaged if they cannot, for example,
use an iterator to find nodes and remove them without destroying the context.
I take it that removal and the many other mutations that might occur (insertion,
etc.) while iterating are not important use cases for you, or you expect the user
to deal with it, correct?
I disagree strongly with having documented conditions where behavior is
undefined, because it will cause code to be commonly written which works on some
implementations and not on others.
Trying to explain to people that they shouldn't have used it in a certain way
because it won't work in other implementations is a little like trying to
convince people to use valid HTML, when what they wrote works on their browser.
Especially if the cases with mutation are important use cases, it is essentiual
that we tie them down.
> The *also* was to mollify the crowd that wants to have robustness at any
> price. In my opinion this should be left as an implementation decision.
I think there are two different possible levels of compatibility with iterators.
1. is the API
2. is the factory/constructor which determines behaviors beyond the API
Different factories would produce completely different iterators. On the surface
might iterate children, another iterates descendants with the a certain tag.
Another could find all the processing instructions, etc. But all of these
different factories conform to the API.
It doesn't seem unreasonable that iterators constructed by different factories
would behave differently under mutation, as well. When users get implementations
of an API from a private factory, they can conform to the fundamentals of the API
but define other behaviors how ever they like.
But I feel that any factory method defined in the DOM API must produce objects
where all significant behavior happens in a single way -- no significant behavior
that is exposed through the API can be left unspecified.
Do you have a problem with this?
Ray Whitmer