- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 2 Apr 2008 10:43:20 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Henri Sivonen <hsivonen@iki.fi>, Boris Zbarsky <bzbarsky@mit.edu>, "Web APIs WG (public)" <public-webapi@w3.org>
On Apr 2, 2008, at 2:44 AM, Jonas Sicking wrote: > > Henri Sivonen wrote: >> On Apr 2, 2008, at 00:48, Boris Zbarsky wrote: >>> OK. So item() would be available on Element after casting it to >>> NodeList in those implementations. I guess you're saying that the >>> cast would not longer be unambiguous if there were multiple >>> NodeLists that might make sense? So childElements couldn't be >>> implemented with a |return this;|? >>> >>> That doesn't seem like such a terrible implementation burden to >>> me, to be honest... >> I'm not claiming it would be awfully hard, but it does change the >> impact of Element Traversal from adding four or five methods on an >> existing class (mere code footprint; super-simple) to adding more >> run-time object instances. And then, there are issues like should >> childElements return the same object every time. And if yes, then >> the implementor needs to add a new pointer to each element node or >> to add a hashtable on the owner document or something along those >> lines. Again, not awfully hard, but still more complex than just >> adding convenience methods on an existing class. > > Sure it's more complex, but it's still trivial. In WebKit, it would be more than one line of code to add a new kind of NodeList. Not a ridiculous amount of code though. However, I think live NodeLists are an anti-pattern. They tend to be horrible for performance in the face of mutation (and even when there isn't mutation, extra objects are allocated). This is part of why I strongly argued for querySelectorAll to return a non-live list. And using indexing is not really any more convenient than using next/ previous methods. I can live with the editor's decision either way on this one. Cheers, Maciej
Received on Wednesday, 2 April 2008 17:43:58 UTC