- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Wed, 2 Apr 2008 00:16:29 +0300
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: "Web APIs WG (public)" <public-webapi@w3.org>
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