W3C home > Mailing lists > Public > public-html@w3.org > July 2009

Re: Clarification on "live NodeList"

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Tue, 07 Jul 2009 22:02:56 -0700
Message-ID: <4A542880.8020304@terrainformatica.com>
To: Maciej Stachowiak <mjs@apple.com>
CC: Jeff Schiller <codedread@gmail.com>, HTML WG <public-html@w3.org>
Maciej Stachowiak wrote:
> 
> On Jul 7, 2009, at 8:35 PM, Jeff Schiller wrote:
> 
>> However, "live NodeList" could also imply that the NodeList itself
>> should be 'live'.  That is, if a class is removed from an element in
>> the DOM then the NodeList object should be updated to reflect that
>> change by removing a node automatically.
> 
> "live NodeList" is supposed to mean that the NodeList itself is live, in 
> the sense that you describe.
> 
>  - Maciej
> 
> 
> 

Slightly out of topic, sorry in advance but...

Liveness of such things is the worst imaginable case. Contradicts all
design principles in GC-able environments like JS. Sigh.

Call 10 times getElementsByName() and you will have 10 dangling lists
that need to be handled on pretty much each DOM structure update (until
GC will occur).

Of course caching and lazy evaluation tricks can be used for
native implementation of document|element.getElementsByClassName() & Co.
but still substantial amount of code should be executed behind.

It is a pity that such non-effective-known-upfront solutions were
put at the foundation of HTML5. We can JIT JavaScript itself up to the
speed of light but such "combinatorial mines" may ruin that crystal
castle at any point.

And yet... Seems like no one need those NodeLists to be alive.
I've never seen requests or even intimations on such requests to
see them alive. Thus is the question: why? for what purpose?

-- 
Andrew Fedoniouk.

http://terrainformatica.com
Received on Wednesday, 8 July 2009 05:03:21 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:47 UTC