Re: [Element Traversal LC] access to element by index

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