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
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
