W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2000

Re: Traversl NodeIterator detach method

From: Joseph Kesselman/Watson/IBM <keshlam@us.ibm.com>
Date: Wed, 11 Oct 2000 12:27:53 -0400
To: "R. Mark Volkmann" <mark.volkmann@home.com>
Cc: <www-dom@w3.org>
Message-ID: <OF77C33D79.1336719D-ON85256975.0058898B@pok.ibm.com>

>It might be a good idea to explain in the Traversal recommendation why
>NodeIterator needs to have a detach method for releasing resources but
>TreeWalker doesn't.

The editors were getting strong direction from the WG to make this chapter
descriptive rather than discursive. A lot of commentary was edited out at
that time. It can be included in the FAQ or other tutorial material, I
suppose.

In this case:

NodeIterator needs to maintain what amounts to a mutation listener on the
DOM, in order to implement its "maintain relative position under document
mutation" semantics. It will continue to update itself even after you have
stopped using it (though one assumes this will cease when it is returned
to the heap). If you are frequently creating and discarding NodeIterators,
there was a concern that the abandoned-but-not-yet-destroyed ones might
impose a significant performance hit. The detach method was added as a way
to say "I'm done with this NodeIterator, so it no longer needs to be kept
in synch with the DOM," thus avoiding that load. This may be most important
in GC-based environments like Java, where an object's abandoment and
termination may be separated by a considerable amount of time.

TreeWalker's "pure current-node" semantics only require a simple reference
to a single (current) node. There's no ongoing computational cost imposed
by an abandoned TreeWalker. Hence no detach method is needed.


(NodeIterator is emphatically not a trivial abstraction. Keeping the design
reasonably simple and efficient took a _LOT_ of work.)

______________________________________
Joe Kesselman  / IBM Research
Received on Wednesday, 11 October 2000 12:28:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:48 GMT