W3C home > Mailing lists > Public > www-dom@w3.org > January to March 1999

Re: Level 2 iterators

From: Arkin <arkin@trendline.co.il>
Date: Fri, 05 Mar 1999 11:03:17 -0500
Message-ID: <36E00045.DDBF5A20@trendline.co.il>
To: Miles Sabin <msabin@cromwellmedia.co.uk>
CC: "'DOM list'" <www-dom@w3.org>

Miles Sabin wrote:
> Indeed. However, the current draft rules out the
> possiblity of any such iterator implementing the
> NodeIterator interface. The upshot is that any future
> APIs defined in terms of NodeIterators (whether standard
> or proprietary) will be forced to either: live with the
> performance characteristics imposed by the need to
> perform fixup; or work directly with Node's parent,
> child and sibling operations. The first option will be
> impractical in many cases. The second is really rather
> a shame ... a standard iterator interface with broad
> applicability would have been a real gain.

I totally agree with you on that one. There are two possibilites. One is
to not define NodeIterator as live. In this case applications cannot
assume that NodeIterator is live and for all intents and pursposes it
might not be so. That is akin to declaring NodeIterator as not live, and
leaves room for defining yet another live NodeIterator.

The other possibility is to define both live and non-live NodeIterator.
An important consideration in the Java language (see my other e-mail) is
that live iterators must be reset or destructed, but non-live iterators
can be left to the garbage collector.

> Agreed, but then my argument with the draft boils down
> to an issue of what the correct selection of basic
> operations is. My view is that live NodeLists and
> NodeIterators with fixup, whilst possibly helpful to the
> less experienced, or pressured, programmer are high-
> level constructs rather than basic functionality. I
> accept the argument they the spec should provide them.
> But they should be in addition to a well chosen set of
> primitives, not a substitute.

I do not agree that NodeIterator is a high level construct, evident I
could not implement one without making changes to the DOM
implementation. Contrary, I was able to write a very efficient non-live
iterator that is DOM independent. By my definition, a non-live iterator
is a high-level construct as it can be implemented using DOM interfaces


> Cheers,
> Miles
> --
> Miles Sabin                          Cromwell Media
> Internet Systems Architect           5/6 Glenthorne Mews
> +44 (0)181 410 2230                  London, W6 0LJ
> msabin@cromwellmedia.co.uk           England
Received on Friday, 5 March 1999 11:09:17 UTC

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