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

On Apr 2, 2008, at 13:20, Jonas Sicking wrote:
> Henri Sivonen wrote:
>> On Apr 2, 2008, at 12:44, Jonas Sicking wrote:
>>>> And to what end? To use indexing instead of list-style iteration.
>>>
>>> Exactly. Something that I would imagine is quite commonly done.  
>>> Note that we're not just talking iterating over a full DOM tree,  
>>> we're also talking about navigating around in a DOM tree from one  
>>> known specific node to another.
>> It seems to me that allowing indexed access to children creates a  
>> similar kind of problem that allowing indexed access to strings by  
>> UTF-16 code unit has created. Allowing app code to index into  
>> platform structures that are most commonly forward-iterated seems  
>> like an anti-pattern in terms of what implementation constraints  
>> are placed if the impression that the app developer gets is that  
>> indexing has the performance properties of array access and that it  
>> is OK to write app code with that assumption.
>
> What makes you think that most users of the DOM-tree does forward- 
> iteration? This is not my experience with the code I've seen. Rather  
> it has been trying to get to specific nodes within a tree.

If one wants a specific node, why not put an id on it and use  
getElementById? Knowing that you want the fifth element child of  
another element requires a priori knowledge of the document tree shape  
anyway. That said, I don't think there's a problem with having a  
getChildElementByIndexThisIsNotGuaranteedToBeArrayAccess() if you  
really want to get the nth element child only instead of iterating  
with an index.

> The same argument can be made for .nextElementSibling, why give  
> forward-iterating access into platform structures that are most  
> commonly index-accessed?


Indeed the argument I made should lead to iterator objects instead of  
either item(n) or nextSibling.

I think one of the major design flaws of the DOM is that it gives two  
views to the tree without specifying the performance characteristics  
of those views. App developers who like linked lists may reasonable  
assume that nextSibling is a mere pointer dereference. App developers  
who like arrays may reasonably assume that item(n) is a mere array  
access. Now DOM implementations are damned either way and have to do  
tricks to make the non-native view fast as well.

(From what I've said so far, it can be guessed that I prefer the  
linked list view. :-)

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Wednesday, 2 April 2008 10:51:58 UTC