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

On Apr 1, 2008, at 23:27, Boris Zbarsky wrote:
> Henri Sivonen wrote:
>> The childNodes feature seems to have caused a lot of complexity in  
>> DOM implementations
>
> Really?  What sort?  I'm only familiar with the Gecko implementation  
> here, but I don't see it causing extra complexity there...

In Gecko, it seems to dictate the internal data model even, by making  
elements hold an array of children. In implementations that use doubly- 
linked sibling lists, the NodeList needs to be kept in sync somehow  
when the underlying linked list is modified.

>> The Selectors API, for example, returns comatose NodeLists (list  
>> dead; nodes pointed to live), which is much better that trying to  
>> make those lists live.
>
> There are tradeoffs both ways.  Which one is better really depends  
> on the expected use cases.  If you expect to walk the whole list,  
> comatose makes some sense.

Also, a comatose list is easier to walk since the indexes don't shift  
when you remove a node during the walk.

>> Moreover, the common implementation pattern is that an Element  
>> object itself is the NodeList returned by childNodes
>
> Really?  You mean document.body.item(5) does the same thing as  
> document.body.childNodes.item(5)?  And that this is "common"?  I  
> must have missed it....

I mean that the getter implementation for childNodes is roughly  
"return this;".

This pattern is used in Crimson, Xerces and GNU JAXP DOM  
implementations. Since Gecko keeps an array of children, I thought it  
was used in Gecko, too, but I didn't check. I should have. Apparently  
the pattern isn't as common in C++.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Tuesday, 1 April 2008 21:17:14 UTC