Re: ActiveNodeSet/StaticNodeSet alternative

Are you saying that the answer to "why not?" is just
"these seem different"?  I hoped for a real justification.

If it's a "set", then the fact that Active ones can invalidate
sure seems like something that non-mutating code would
be able to ignore (except for error reporting) given half a
chance.  What's the justification for preventing that?

Library code might quite reasonably be able to accept
either kind of NodeSet implementation.  The current
scheme requires double the number of such library APIs,
by pushing implementation attributes into the interface
even for cases where those attributes are irrelevant.

- Dave


----- Original Message ----- 
From: "James Melton" <james.melton@cylogix.com>
To: <www-dom@w3.org>
Sent: Thursday, July 05, 2001 1:44 PM
Subject: Re: ActiveNodeSet/StaticNodeSet alternative


> These seem to me like distinctly different use cases as previously
> indicated. Under what circumstances might an application start with one
> of these and subsequently migrate to the other? 
> 
> Jim.
> 
> David Brownell wrote:
> > 
> > > 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.
> > 
> > Why not?  It's easy enough to define a base interface so that the
> > sharable operations can be shared.  Not all users expect to be
> > mutating the tree; why pessimize those other use cases?
> > 
> > Sounds like what's been achieved is "must decide" (early),
> > not "can decide" (later, if it's important).
> > 
> > - Dave
>

Received on Thursday, 5 July 2001 17:35:06 UTC