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

RE: Alternative to the Live NodeIterator

From: Andrew n marshall <amarshal@usc.edu>
Date: Sun, 3 May 1998 10:45:02 -0700
To: "David Brownell" <David.Brownell@Eng.Sun.COM>
Cc: <www-dom@w3.org>
Message-ID: <000401bd76bb$33567d30$48e37d80@philica>
> > 2) The current node is undefined if it is deleted. The spec could
> define it
> > in some way or another, but as I recall the discussion none of the options
> > were without problems.  Plus, this STILL requires that iterators update
> > their state whenever a delete occurs ...
>
> Hmm, my reading says that there are no nodes in a "deleted" state; they're
> just detached from some other node.  So there's no need to have iterators
> interacting with Node.remove!  (I just persuaded myself of that ...)

Unfortunately it isn't that easy.  If the iterator was acting as a filtered
snapshot, you would be correct.  However, the iterator is currently defined to
be live, with a filter relative to the to either an element or the Document
(obviously this should be managed by your proposed revision to the document
fragment).  Therefore removed nodes are also removed form the context of the
filter and should not be returned by the iterator.



> That is, one would define iterators as encompasing a "current node" and
> a "traversal algorithm" (such as "siblings", "children", "preorder depth
> first"; perhaps filtering out some kinds of nodes).  Then there would be
> two cases in node removal, ones that are familiar to anyone who's ever
> edited a linked list:

I'm not sure I understand you.

>     - You removed the node since it's the one you're interested in.
>       Don't touch the iterator; remove the current node from its
>       parent, and that iterator just shows the good parts.

What are 'the good parts'?  And if you you don't touch the iterator, isn't it
still pointing to the removed node?

>     - You removed the node since it's the one you're NOT interested in.
>       Before you remove it, move the iterator to some other node.

Why would the iterator ever point to a node it is not interested in?

> Completely natural for single threaded code, and it's got relatively
> nice behaviour for concurrent mutating/traversing threads (assuming
> they coordinate somehow).

Could you please re-explain how you intend to implement iterators/node removal
without interaction between the two.


Andrew n marshall
  student - artist - programmer
     http://www.media-electronica.com/anm-bin/anm
      "Everyone a mentor, Everyone a pupil"
Received on Sunday, 3 May 1998 13:37:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:45 GMT