Re: Implementing NodeList

David Brownell <db@Eng.Sun.COM> writes:

> > There was a lot less inefficiency in the implementation when there were
> > iterators; each implementation of the NodeList interface could return the
> > most appropriate implementation of Iterator. 
> 
> Some of us would differ ... all those iterators were "live",

TreeIterator was, but I read NodeIterator as being live only when it
referred to the children of a single node; otherwise it just enumerated the
contents of a NodeList that could be implemented as a list of nodes.

> and since there was no current element you were severely
> constrained in terms of implementation.  Just try to modify
> the tree and keep the "liveness"; hey, that's where this very
> discussion got (re)started!  :-)

The fact that there was no current element in the spec didn't mean that you
couldn't have one in the implementation.  (Of course, if the tree got
re-arranged between calls on the iterator, the ``next'' node could be pretty
much anywhere.)

> In the meanwhile, it's pretty simple to write an iterator
> class (say, in Java) to do a breadth first traversal over
> the tree and let you visit the appropriate nodes.

Which I've done.  What I really miss is being able to ask a NodeList for its
iterator and getting the appropriate one for its implementation.  I agree
that TreeIterator was over-elaborate, and I never got around to implementing
it in full glory because what I really needed was a one-pass depth-first
traversal of a tree that was never modified (but which _might_ be under
construction -- we essentially treat a parser as an iterator over a tree
that doesn't quite exist).

-- 
 Stephen R. Savitzky   Chief Software Scientist, Ricoh Silicon Valley, Inc., 
<steve@rsv.ricoh.com>                            California Research Center
 voice: 650.496.5710   fax: 650.854.8740    URL: http://rsv.ricoh.com/~steve/
  home: <steve@starport.com> URL: http://www.starport.com/people/steve/

Received on Monday, 27 July 1998 19:03:06 UTC