W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2011

Re: [DOMCore] Traversal

From: Anne van Kesteren <annevk@opera.com>
Date: Mon, 01 Aug 2011 14:21:20 +0200
To: www-dom@w3.org, "David Flanagan" <dflanagan@mozilla.com>
Message-ID: <op.vzja9u1r64w2qv@annevk-macbookpro.local>
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.


-- 
Anne van Kesteren
http://annevankesteren.nl/
Received on Monday, 1 August 2011 12:21:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:08 GMT