W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2001

Re: ActiveNodeSet/StaticNodeSet alternative

From: Ray Whitmer <rayw@netscape.com>
Date: Thu, 05 Jul 2001 12:52:31 +0000
Message-ID: <3B44630F.4000509@netscape.com>
To: "Arnold Curt" <Curt.Arnold@hyprotech.com>
CC: "'www-dom@w3.org'" <www-dom@w3.org>
Arnold, Curt wrote:

>The basic distinction between ActiveNodeSet and StaticNodeSet 
>is whether the node set is assembled at the time of the query 
>versus at the time an individual node is accessed in the node set.  
>However, ActiveNodeSet and StaticNodeSet have radically different 
>signatures which would make it impossible to write code that 
>could readily switch between evaluation modes.  This requires 
>the code author to make an apriori decision on which method 
>is going to be more efficient and makes it difficult to check 
>the assumption.
I think you missed the point of ActiveNodeSet and StaticNodeSet.  It is
not so that the application writer can decide which one he thinks would be
quicker, but rather so that he can decide which one he can deal with,
since it was clear from several sources that each is a use case.  A program
that relies on an ActiveNodeSet is likely to not work with a StaticNodeSet
and vice versa, even if the APIs were identical, because users of
ActiveNodeSet can assume that the nodes are always still in the tree,
but he cannot mutate the tree without invalidating his set, can only
assume that he can mutate the tree without invalidating the list.

>It seems cleaner to me to have just the NodeSet interface 
>with item() and length() methods and to add a boolean parameter, 
>something like "lazyEvaluate" or similar, that, when true, allows 
>the processor to lazily evaluate the node set if it wants.
There is nothing preventing an ActiveNodeSet from doing complete
evaluation up front or a StaticNodeSet from doing lazy evaluation
(until the first mutation occurs, at which point it would have to
complete the computation before permitting the mutation).  There is
no reason the caller has to know how it was implemented.  The caller
merely needs to know whether he wants a representation that
invalidates or one that gets out of sync.  This is clearly a choice that
the caller, and not the implementor should make, because if the
implementer makes the choice, the code will break.

>Implementations that did not expect lazy evaluation to 
>offer significant advantages could simply ignore the
>lazy parameter.
They can do this already with the current proposal.  There is nothing
stopping an ActiveNodeSet from evaluating completely or a
StaticNodeSet from working incrementally (until the first mutation
and then quickly finishing).

Ray Whitmer
Received on Thursday, 5 July 2001 15:48:06 UTC

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