

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 01 Apr 2008 16:30:06 -0500
Message-ID: <47F2A95E.8090600@mit.edu>
To: Henri Sivonen <hsivonen@iki.fi>

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.

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