- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 07 Jul 2009 22:44:00 -0700
- To: Andrew Fedoniouk <news@terrainformatica.com>
- Cc: Jeff Schiller <codedread@gmail.com>, HTML WG <public-html@w3.org>
On Jul 7, 2009, at 10:02 PM, Andrew Fedoniouk wrote: > > 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? I agree with you that the concept of live NodeLists is not great. However, in the case of getElementsByName, this is required by the DOM spec and by backwards compatibility. For getElementsByClassName, it makes sense to align with ...ByName, ...ByTagName and ...ByTagNameNS as specified by DOM Core. However, because of the complexity with dynamic NodeLists, the new Selectors API (querySelectorAll) uses static NodeLists instead. It can replace the functionality of all the getElement[s]By... series of functions and more. <http://www.w3.org/TR/selectors-api/> Regards, Maciej
Received on Wednesday, 8 July 2009 05:44:49 UTC