- From: Ray Whitmer <ray@imall.com>
- Date: Wed, 18 Nov 1998 12:41:47 -0700
- To: www-dom@w3.org
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
Received on Wednesday, 18 November 1998 14:43:00 UTC