Re: Behavior of NodeIterator.toNext()

TAMURA Kent writes:
 > NodeIterator ni = some_node.getChildNodes();
 > Node node = ni.toNext();
 >
 >In this code, is a variable `node' the first child? Or second
 >child?

I plead for an explicitly "undefined" position where getCurrent() returns null.
The iterator could move to this undefined position whenever it discovers that
its current node has been removed from the sequence.  The only ways to leave
this position are the ones suggested by David below, toNext and toPrevious just
leave the iterator in the undefined position.  This solution should be fairly
easy to implement and has a defined behaviour under all circumstances.

David Peterson writes:
 > [..]  The only way to be
 > sure that you are where you think you are is to call one of the other "to"
 > methods - 'toFirst', 'toLast', 'toNth', or 'toNode'.  If the list is already
 > there, it shouldn't be an expensive call.  If it isn't, you are now in the
 > correct place.  It's the only way to guarantee.

I just wondered if toNth gives a relative or an absolute position?  The
definition says "relative to the current position", but the exception is thrown
"if the value specified is greater than the number that would be returned from
getLength()", which seems to imply an absolute position (which is also my
interpretation of the name "toNth").  Any suggestions on this?

Earlier, David Peterson writes:
 > I would say that this [position] is unknown.  Since the NodeIterator is
 > "live", it makes sense for the same iterator to be used every time
 > getChildNodes is called.  It is definately not specified what should happen.

Here I disagree. The iterator pattern was specifically designed so there can be
many iterators on the same sequence at the same time (e.g. if you need all
combinations of subnodes).  In a multithreaded setting, this is even more true:
Independent programs could operate on the same node, and should each get their
own iterator.  Since there is no "close" method for iterators, the
implementation can never be sure that one part of the program is done with the
iterator, so it can't reuse the iterator for another part.

Greetings,
	Axel
----------------------------------------------------------------------
+ Axel Rasmus			 "..."			    Wienberg +

Received on Tuesday, 7 April 1998 09:05:34 UTC