W3C home > Mailing lists > Public > www-dom@w3.org > April to June 1998

Re: Hello and NodeIterator Revisited

From: Mike Champion <mcc@arbortext.com>
Date: Thu, 30 Apr 1998 16:14:23 -0400
Message-Id: <98Apr30.161553edt.26884@thicket.arbortext.com>
To: "Don Park" <donpark@quake.net>, "www-dom" <www-dom@w3.org>
At 03:37 PM 4/30/98 -0400, Don Park wrote:
>Hello there.
>I would like to point out some of the problems of the NodeIterator design.
>1. Mixing iteration operation with indexing operation is not a good.  It is
>confusing as well as burdening the implementors unnecessarily.

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.

>2. Implementing the 'between' concept of position is elegant but makes
>efficient implementation in Java very hard if not impossible.  Due to 'live'
>aspect of iterators, each iterator has to be attached to the 'link' between
>two siblings.  Cost of object instantiation is heavy in Java.

Part of the reason for doing this was to emulate that familiar behavior of
the java.util.Enumeration interface.  We've extended the functionality,
certainly, but not the fundamental concept.  Again, I'd be glad to hear in
more detail your argument that this would make efficient implementation
difficult, and would entertain any better idea.  The "old" way (having
iterators point to Nodes) would have caused us to have to define all sorts
of ad-hoc behavior if the "current" node was deleted, or modified, or
moved, or a new node inserted before or after it, etc.  

>3. NodeIterator should have a 'release' method to make it possible for the
>target node to keep track of active iterators.  C++ has destructor, Java's
>finalize is less than useless.

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.  Again, if the "tree" needs to keep track of
iterators rather than the iterators simply keeping track of where they are
in the tree, I could see your point, but I'd have to be convinced ...

>4. Using NodeIterator to iterate an element's Attribute is not wise since
>most of the Node methods do not make sense if Attribute interface extends
>Node interface.

Sorry, I don't follow.  Could you re-state this?

>But then I would prefer to have the API settled
>down more than anything. 

So would we all, let me assure you!  But an API such as the DOM must meet
NUMEROUS constraints, and finding our way through all of them has been
rather difficult.  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. 


Mike Champion
Received on Thursday, 30 April 1998 16:17:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:03 UTC