Re: [DOMCore] Traversal

On 8/1/11 5:21 AM, Anne van Kesteren wrote:
> On Sat, 30 Jul 2011 02:05:24 +0200, Anne van Kesteren 
> <annevk@opera.com> wrote:
>> On Fri, 29 Jul 2011 16:47:18 -0700, David Flanagan 
>> <dflanagan@mozilla.com> wrote:
>>> 3) The referenceNode/pointerBeforeReferenceNode pair seems like a 
>>> complicated and ugly way to represent the state of a NodeFilter.  Is 
>>> there any way to do better?  Could you at least change "pointer" to 
>>> "cursor"?  Or, what if the state was instead represented by a pair 
>>> of next and previous attributes, each of which was a Node or null?  
>>> These would be two adjacent nodes and the cursor position would be 
>>> between them.  nextNode() would always return the next attribute and 
>>> previousNode() would always return the previous attribute, but the 
>>> methods would then adjust the cursor position. This would also give 
>>> developers an option to peek at the next or previous node without 
>>> moving the cursor.  I haven't tried to work the algorithms using 
>>> next and previous as the state variables, but it I think that a 
>>> next/previous pair carries the same information as 
>>> referenceNode/pointerBeforeReferenceNode.  And my intuition tells me 
>>> that the algorithms would be simpler when defined in terms of 
>>> next/previous.
>>
>> Interesting idea. I am not sure if we can change the API additions at 
>> this point though.
>
> I thought about this some more and I do not think this makes sense 
> anymore. You cannot know the next node without running the filter 
> algorithm and you do not want to run that until you actually want to 
> get the next node. Well, unless you want to change the semantics of 
> the original NodeIterator object but that seems like a bad idea.
>
>
I thought about this some more over the weekend myself and realized that 
a next/previous pair is not enough state.  For dealing with insertions 
and deletions it is also necessary to know which of the two nodes the 
cursor "sticks" to.  That's what you've got with 
pointerBeforeReferenceNode, even though it has a horrible name :-)  And 
given that pointerBeforeReferenceNode is already deployed, I retract my 
suggestion.

     David

Received on Monday, 1 August 2011 14:31:02 UTC