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

RE: Alternative to the Live NodeIterator

From: Mike Champion <mcc@arbortext.com>
Date: Fri, 1 May 1998 23:04:23 -0400
Message-Id: <98May1.230428edt.26886@thicket.arbortext.com>
To: David.Brownell@eng.sun.com (David Brownell), peter@sqwest.bc.ca
Cc: www-dom@w3.org
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:

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.

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

3) The current node is counter-intuitive if it is moved to a different
position in the list.

I read the objections to this, and none of them resonate with me
(admittedly it's late on a Friday night ...).  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).


3) T
Received on Friday, 1 May 1998 23:06:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:03 UTC