- 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