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
