- From: David Brownell <David.Brownell@Eng.Sun.COM>
- Date: Sat, 2 May 1998 11:34:15 -0700
- To: mcc@arbortext.com, peter@sqwest.bc.ca
- Cc: www-dom@w3.org
> Date: Fri, 1 May 1998 23:04:23 -0400
> From: Mike Champion <mcc@arbortext.com>
>
> At 07:05 PM 5/1/98 -0400, David Brownell wrote:
> >The problem of updating that relative positioning info goes away if
> >iterators have a "current" node. No fuss, no bother. No information
> >about position relative to that node, needing to be stored or updated.
>
> We had this until the last draft. The problems (and other WG members
> please help me refresh my memory here) were:
Ah, so it's a _new_ problem! That explains some of the confusion
I noticed in the archive.
> 1) The current node is undefined when an iterator is constructed; you have
> to to an explicit getFirst() or getLast() or whatever; any definition of
> what getNext() would return as the first call after the iterator is
> constructed is somewhat arbitrary. If the cursor is initially positioned
> BEFORE the first node, this problem goes away.
More simply, the API spec of each iterator creation act would
specify the "current" node of that iterator. Plus of course,
there'd be a getCurrent() method.
> 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 ...)
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:
- 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.
- 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.
Completely natural for single threaded code, and it's got relatively
nice behaviour for concurrent mutating/traversing threads (assuming
they coordinate somehow).
> 3) The current node is counter-intuitive if it is moved to a different
> position in the list.
See above -- depends entirely on why you're iterating. If iterating
is for displaying the current document, then you certainly want it to
reflect that modified structure. But if you're doing a topological
transform (say, references at end v. inline) then you'd be using the
other behaviour.
> Like Peter, I'm not rabidly
> opposed to a "release" method on iterators (or other DOM objects), but am
> far from persuaded that they add anything useful (especially for ECMAScript
> programmers, who are not going to think about "freeing" resources).
But the ECMA Script programmers are going to have to use that method
too, and for the same reason. It'll be a lot better if it's fixed
more along the lines I suggested, than by adding a "free" method.
- Dave
Received on Saturday, 2 May 1998 14:34:25 UTC