W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2012

Re: An iterable DOM

From: Cameron McCormack <cam@mcc.id.au>
Date: Thu, 21 Jun 2012 11:13:10 +1000
Message-ID: <4FE27526.4010801@mcc.id.au>
To: Jason Orendorff <jason.orendorff@gmail.com>
CC: public-script-coord <public-script-coord@w3.org>
Jason Orendorff:
> I could imagine NodeList.prototype.iterator returning an actual DOM
> NodeIterator, rather than using the builtin Array.prototype.iterator.
> That would be robust against changes to the front of the array while
> it's being iterated. But an Array.prototype.iterator might run faster.

I see.  If NodeList.prototype.iterator did return a NodeIterator, then I 
guess that interface would need a next() method that behaved like:

   NodeIterator.prototype.next = function() {
     var n = this.nextNode();
     if (!n) throw StopIteration;
     return n;
   };

If we want to allow APIs to be defined that return things other than 
generator functions from iterator(), then we could allow say:

   interface NodeList {
     Node iterator = NodeIterator;

     // the interface name on the rhs gives the type of iterator object
     // to return, rather than a generator function (as it would be
     // in the ES binding)
   };

   interface NodeIterator {
     // ... the members of NodeIterator ...
     Node next;

     // next would be a keyword that makes NodeIterator be considered
     // an iterator type -- in the ES binding it would just correspond
     // to a next() method that returns a Node or throws StopIteration
     // (although prose defining NodeIterator.next's behaviour would
     // not need to mention StopIteration explicitly)
   };

>> By "DOM iterators" above did you mean NodeIterators and TreeWalkers from DOM
>> Traversal:
>> http://www.w3.org/TR/DOM-Level-2-Traversal-Range/traversal.html#Traversal-NodeIterator
>
> I meant NodeIterators. Maybe we don't care. I don't mean to take off
> into the weeds here.
>
> WebIDL could provide an empty Iterator interface, with understanding
> that each language has to specify what that means. So we could have
> 'interface NodeIterator : Iterator', and in ECMAScript, that means
> that NodeIterator.prototype inherits from the builtin
> Iterator.prototype, and there's a NodeIterator.prototype.next method
> that throws StopIteration when it hits the end.

Yeah that would be another way to do it.  I think it would be preferable 
though to annotate an interface as being an iterator, rather than 
inheriting from some special Iterator interface, because at least for 
NodeIterator I don't think you would want to want or need to inherit 
from an Iterator.prototype -- there wouldn't be anything useful to 
inherit from there, at least.
Received on Thursday, 21 June 2012 01:13:45 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:06 UTC