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

RE: Alternative to the Live NodeIterator

From: David Brownell <David.Brownell@Eng.Sun.COM>
Date: Fri, 1 May 1998 11:26:45 -0700
Message-Id: <199805011826.LAA25027@argon.eng.sun.com>
To: peter@sqwest.bc.ca, www-dom@w3.org
[ Diving in to this discussion late, sorry if I'm missing context! ]

> Right. Some object -- and the document tree is a logical choice -- must
> maintain a reference to iterators.

This seems to derive from the need to be able to identify some
abstract position "between" iterated nodes.  If the iterator had
a "current node", I don't think such a reference would ever be
needed, since simple algorithms would suffice to always find
the next/previous/first/last nodes and, for tree iterators, the
firstchild/nextchild/firstsibling/nexsibling nodes.

Is anyone claiming that the indexed access model makes sense on
a live NodeIterator, by the way?

> >And as Don Park also mentioned, these reference need a release mechanism.
> In the subset of language bindings which garbage collect -- I'll include
> ECMA Script and COM in that category -- I don't believe there is a
> requirement for adding a release mechanisms to the DOM API. Doesn't Java
> also fall into the same category?

Java garbage collects ...  but the "reference(s) to the iterators"
that's maintained by "some object" to maintain "live" semantics will
preclude collecting any those iterators as garbage!  Iterators will
always have live references, hence can't be GC'd.

COM has explicit reference counting, not GC.  Like all "Pure C" APIs,
the memory management must be explicit.

- Dave
Received on Friday, 1 May 1998 14:26:52 UTC

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