Re: Hello and NodeIterator Revisited

At 07:11 AM 5/1/98 -0400, Jeff wrote:

>A collection holds things, an iterator traverses a collection of things.
>They are two entirely distinct concepts. The collection should support three
>basic operations: adding things to the collection, removing things from the
>collection, and accessing individual things in the collection (by index, by
>name, by sequence). An iterator should support traversal.
>
>Mixing abstractions is rarely a good idea--and the latest DOM does that in
>at least two areas. (using Nodes as collections and using NodeIterators
>without specifying a NodeList and a NamedNodeList) 

I'm not responding as the spokesman for the WG, but just as someone who's
personal opinion is closely in line with the way the spec currently reads.
So, here is my $.02, which I think is mostly congruent with majority
opinion on the WG, but I can't say for sure:

FWIW, the WG recently agreed to use NodeIterators for all collections.  As
far as NodeIterators, Nodelists/NamedNodeLists go, the WG has spent a very
very large proportion of its time on this.  I for one have become rather
enamored of the current draft's position that NodeIterators represent a
higher-level abstraction (some call it a "Collectionator") that combines
the semantics of both collections and iterators.   Outside of the DOM
context, I'd be somewhat inclined to agree that "collection" and
"iteration" are quite different abstractions.  But in the DOM context,
remember that "collections" are basically sets of Nodes that already exist
in the document tree, not collections of things that have some separate
identity.  

One could imagine specifying "collections" as copies of Nodes out of the
tree, but that has efficiency problems, and has the additional problem that
without an Event model (which we deferred until DOM level 2) it's more or
less impossible to keep the copies in the collection in synch with the
master nodes in the tree.

I agree that an object model that separates collections and iterators, and
uses events to allow coordination between a collection and the tree will
work... It's pretty much how the IE4 object model works, I believe.  But I
prefer the DOM API's notion of having the "collection" be the underlying
tree and the add/remove operations operate on the underlying tree, then
adding functionality to NodeIterators to locate objects by index and name
AS WELL AS iterating over them in the conventional manner.  

It's also obvious that we need to explain this reasoning in the DOM API
spec somewhere ... and there are still changes being discussed, so feel
free to keep challenging the NodeIterator model.

> Two of the most common
>implementation languages (C++ and Java--undoubtedly the majority) have
>memory management requirements. I'd actually prefer to see a "release"
>method on each "base" interface--Node, NodeList (if it ever makes its way
>back into the spec), Without the method in the spec, each implementation is
>free to implement its own memory management, reducing the portability of
>clients.

I personally see adding memory management hooks as a last resort ... but
feedback from implementers of the DOM API is what could get me to change my
mind!

Thanks for your comments,

Mike

Received on Friday, 1 May 1998 11:45:10 UTC