Re: indexOf in DOM Core L3

Jonas Sicking wrote:

>Hi,
>
>There is one thing i've been missing in the DOM Core interfaces since I
>started using the DOM implementation in Mozilla (for example when
>implementing the DOM TreeWalker and the mozilla XSLT implementation). It
>would be usefull with a way to get the index of a node withing a NodeList or
>a NamedNodeMap. This could of course be done by simply iterating the
>children until the right one is found, however this can probably be done
>much faster as an internal method inside the NodeList/NamedNodeMap.
>
>So I propose the following method on the NodeList and NamedNodeMap
>interfaces:
>
>  unsigned long indexOf(in Node item)
>            raises(DOMException)
>
>  returns the index if the node item
>  raises NOT_FOUND_ERR if item is not contained in the
>NodeList/NamedNodeItem
>
>
>A similar method exists on some of the internal interfaces in mozilla and is
>rather commonly used, however it would be nice to not have to rely in
>internal interfaces and be able to use standard DOM interfaces instead.
>
Here are some thoughts off the top of my head:

It is not clear that you have significant use cases for this or that 
relying the index number of a child within a list is something that 
should be encouraged.

In many cases a sequential search is required to get this information. 
 This can be related to the DOM implementation or the particular 
operation (such as finding all nodes by element name).  Providing a 
convenience function might make people believe this is inexpensive when 
it is not.  Having live NodeLists in the first place is considered ugly 
by many, and adding this wouldn't make it any prettier.  In cases 
besides child lists, most implementations might wind up doing the 
sequential search in most cases.

My own DOM implementations have included a private childIndex on Node 
rather than on NodeList, because at least then, the requirement is 
restricted to children, which in my implementations have been directly 
indexable.  Implementations for which this is not true may find this 
ugly, too, encouraging people to do random access operations which do 
not perform well in the implementation.  The more relationships that the 
framework is required to efficiently expose, the worse the 
implementation gets.  If I had it to start over from scratch, I would 
eliminate much of what is there now including parent and sibling 
pointers on nodes.

Ray Whitmer
rayw@netscape.com

Received on Wednesday, 30 January 2002 11:05:59 UTC