- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Tue, 07 Jul 2009 22:02:56 -0700
- 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