Re: Hello and NodeIterator Revisited

Mike,

>>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.

Indexing operations belong with the container whose contents are being
indexed.  Given that the content can change at anytime, exception throwing
should be minimal so that following code will simply no-op if the last child
is removed:

int n = node.getChildCount();
Node child = node.getChildAt(n - 1);
if (child != null) { ... }

Child count also belongs at the container rather than with the iterator.

Iterator pattern is very similar to Visitor pattern, primary difference
being that Iterator is proactive (client controls the movement) while
Visitor is reactive (target structure controls the movement).  Asking the
iterator to do indexing operation is as useless as asking it "how many
children do you see now?" or "get me the fifth of the children you see right
now!".

When dealing with 'live' structures, Visitor pattern is much more
appropriate because the object being visited can keep track of changes to
itself more easily than an external object like iterator can and control the
visitor appropriately.  Visitor pattern is most easily implemented as Events
in languages like ECMAScript.

If having the latest information is critical, Events should be used.
Iteration should be left alone for simple relative traversal over a
'snapshot'.  A method that 'possibly' take a long time and return 'possibly'
bogus value is 'definitely' useless in my book.

>>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.

Rather than trying to explain why the current NodeIterator design is hard to
implement efficiently in Java, I challenge you to write an efficient
implementation in Java.  I also challenge you to write example programs
which benefits substantially from the 'live' NodeIterator design.  Scars are
easier earned than explained.

>>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 ...

Finding no resonance to my concerns, I withdraw my comment regarding
'release'.

>>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?

There is nothing in the spec that requires an Attribute to be a Node as
well.  Having to use NodeIterator for Attributes now requires Attribute to
be a Node.

Regards,

Don Park
http://www.docuverse.com/personal/index.html

Received on Friday, 1 May 1998 05:14:47 UTC