This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 17648 - [Awaiting ES6] Add iterators
Summary: [Awaiting ES6] Add iterators
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebIDL (show other bugs)
Version: unspecified
Hardware: PC Windows 3.1
: P2 normal
Target Milestone: ---
Assignee: Cameron McCormack
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 23210 23211 23212 26102 26183
  Show dependency treegraph
 
Reported: 2012-06-29 08:32 UTC by Anne
Modified: 2014-10-05 17:11 UTC (History)
10 users (show)

See Also:


Attachments

Description Anne 2012-06-29 08:32:11 UTC
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.
Comment 1 Ms2ger 2012-06-29 09:01:03 UTC
I think this should be done in WebIDL for all interfaces that support indexed properties, fwiw.
Comment 2 Anne 2012-12-13 10:55:30 UTC
heycam, what do you think?
Comment 3 Cameron McCormack 2012-12-14 05:31:35 UTC
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.
Comment 4 Cameron McCormack 2012-12-14 05:57:10 UTC
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.
Comment 5 Cameron McCormack 2014-01-27 21:45:20 UTC
Thread at http://www.w3.org/mid/520FE9BF.5060902@gmail.com mentioned this bug too.
Comment 6 Anne 2014-02-12 19:46:45 UTC
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."
Comment 7 Boris Zbarsky 2014-02-12 21:13:00 UTC
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.  :(
Comment 8 Cameron McCormack 2014-09-29 04:12:28 UTC
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
Comment 9 Cameron McCormack 2014-09-29 04:28:43 UTC
(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".
Comment 10 Boris Zbarsky 2014-10-04 04:38:48 UTC
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.
Comment 11 Cameron McCormack 2014-10-04 05:01:16 UTC
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 }.
Comment 12 Cameron McCormack 2014-10-04 05:10:00 UTC
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.
Comment 13 Allen Wirfs-Brock 2014-10-05 17:11:46 UTC
(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