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