- From: Cameron McCormack <cam@mcc.id.au>
- Date: Thu, 21 Jun 2012 11:13:10 +1000
- 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