Re: Hello and NodeIterator Revisited

>>1. Mixing iteration operation with indexing operation is not a good.  It
is

>>confusing as well as burdening the implementors unnecessarily.

Probably a valid argument--if I have a C++ implementation (or Java for that
matter) that uses linked lists, indexed access will be inefficient. That
doesn't mean it can't be done, but is there a compelling reason to keep the
methods in NodeIterator?

>Could you elaborate please?  At one time, we had a NodeList class for
>"collection semantics", but by adding only a few additional methods to
>NodeIterator we got the same functionality.  We realize that this is
>unconventional, but it seems to minimize the number of classes at a minimal
>cost. If there are arguments against this that we haven't already
>considered, I for one would listen.

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) Reducing the size of an
API is great, as long as the API remains consistent AND intuitive. The
questions (flack?) that you're getting about the current API should be an
indication that it isn't as intuitive as it could be.

>We're going to add a technical discussion of our philosophy on this general
>issue; basically, we don't want the DOM to have to expose memory management
>functions.  This may become necessary in some languages/implementations,
>but not in the general case.

This is a common ideal, that is often relaxed in "release 2" of a
specification. In an ideal world, we wouldn't have to worry about memory
management. In real implementations, we do.  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.

>It's very important to get this "right" before it is
>proposed to the W3C, and we have benefitted greatly from the feedback you
>all have provided.

I agree. And from our side, the opportunity to review the standard--and get
feedback from the contributors--has been very valuable.

Jeff Mackay
Vtopia, Inc.
url: http://www.vtopia.com/
e-mail: jmackay@vtopia.com

Received on Friday, 1 May 1998 07:11:24 UTC