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

Henri Sivonen wrote:
> In Gecko, it seems to dictate the internal data model even, by making 
> elements hold an array of children.

This has more to do with memory usage considerations than the DOM API, for what 
it's worth...  Using a doubly-linked list simply takes more memory per node.

But yes, the array data storage does make it fast to implement index access, 
while also allowing reasonably fast next/prevSibling access a long as the 
next/prevSibling getter is not called on completely random nodes.  Which it's 
not, usually.

One could just as easily use a doubly linked list and have fast next/prevSibling 
and reasonably fast index access as long as the indices accessed are not 
completely random.  Which they aren't, usually.

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

Sure.  If you plan to actually _modify_ the DOM while walking the list, then 
comatose lists are much nicer in all sorts of ways.  I'm not sure there's a 
correct way to walk a non-comatose list while modifying the DOM unless you 
prohibit mutation events from modifying the DOM.

>> 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.

That doesn't really answer my question.  Are all the same properties available 
on |this| and |this.childNodes|?  If so, that seems pretty odd to me (though not 
actually prohibited by the DOM spec, of course).  If not, I'm not sure what the 
concern over namespace collisions was.

-Boris

Received on Tuesday, 1 April 2008 21:31:19 UTC