This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
http://lists.w3.org/Archives/Public/public-script-coord/2012AprJun/thread.html#msg239 heycam suggests at least NodeList/HTMLCollection need this, but if they can have [ArrayClass] that would be better. https://bugs.webkit.org/show_bug.cgi?id=81573 suggests [ArrayClass] is probably not going to happen, but who knows, it is not resolved wontfix just yet.
I think this should be done in WebIDL for all interfaces that support indexed properties, fwiw.
heycam, what do you think?
Iterators have already been added to the spec, so if people want to write explicit ones for their interfaces they can. http://dev.w3.org/2006/webapi/WebIDL/#idl-iterators http://dev.w3.org/2006/webapi/WebIDL/#es-iterators But I like the idea of having iterators by default for objects that support indexed properties. This could be overridden if you explicitly declare an iterator.
The ES6 draft has changed a lot since I looked at it last. :) I can't see mention of iterator() methods on objects any more, which is what Web IDL is written against at the moment. Maybe that strawman changed before being added to the spec. I can see in section 12.6.4 (dealing with for-in and for-of loops), the runtime semantics of the "For In/Of Expression Evaluation" abstract operation, step 7.b says: Let keys be the result of performing Invoke with arguments obj, %iterator%, and an empty List. but there doesn't seem to be a definition for this intrinsic object %iterator%. Maybe that's meant to be an intrinsic symbol @@iterator? Anyway, it feels like the spec isn't quite done on this yet, so perhaps I should wait a bit.
Thread at http://www.w3.org/mid/520FE9BF.5060902@gmail.com mentioned this bug too.
Given that we could theoretically snapshot live lists, I asked arv, he said "I think we should keep them live. ArrayIterator is live. Doing `NodeList.prototype[Symbol.iterator] = Array.prototype[Symbol.iterator]` works fine with live lists."
Fwiw, that's basically what Gecko implements right now. We've had a few complaints about it, in the usual way. Live lists suck to work with. :(
I've updated the spec to use @@iterator and reference other abstract iterator-related operations from the ES6 spec. I've removed interface interfaces, as they were a complication that I'm not sure we need. I've also updated the iterator that exists automatically due to declaring indexed properties to just use the default Array iterator. An easier way to iterate over a set of objects -- bug 26183 -- is still to come. https://github.com/heycam/webidl/commit/f87ea39994972ebd75f4b98c2dc01a32aaa9d1f5
(In reply to Cameron McCormack from comment #8) > An easier way to iterate over a set of objects -- bug 26183 -- is still to > come. "list of values", not "set of objects".
Do we actually want to make the @@iterator property enumerable? It doesn't affect for..in enumeration either way, since that skips symbol-named props, but it seems like we might want to not make it enumerable in general.
Oh, I think we should be using the defaults mentioned in https://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-standard-built-in-objects, i.e. { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }.
Fixed that: https://github.com/heycam/webidl/commit/650316df6cdd154fd759a9d5b5130a67ce142aa1 I wasn't sure what to do about @@toStringTag, as some properties with this name in the ES6 spec are configurable and some are not. Just added an ednote for now.
(In reply to Cameron McCormack from comment #12) > I wasn't sure what to do about @@toStringTag, as some properties with this > name in the ES6 spec are configurable and some are not. Just added an > ednote for now. That's a bug in the ES6 spec (now fixed in my draft) All standard @@toStringTag properties should be non-writable (unless an accessor), non-enumerable, and configurable