W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2014

[Bug 26183] make it easier to define an iterator on an interface that iterates over a set of values

From: <bugzilla@jessica.w3.org>
Date: Thu, 02 Oct 2014 07:22:36 +0000
To: public-script-coord@w3.org
Message-ID: <bug-26183-3890-IiAEquRbPz@http.www.w3.org/Bugs/Public/>

--- Comment #20 from Anne <annevk@annevk.nl> ---
1) We want "iterator;". HTMLCollection is something where we cannot expose
additional methods, but we want to expose Symbol.iterator.

2) I think we want a way to return an iterator similar to "iterator;", but for
normal methods rather than Symbol.iterator. This would allow "polyfilling" at
the standards level. E.g. with that I could define keys() and friends myself.

3) I would expect all iterable objects to have forEach(), not just maplikes.
Iterating over the same values as Symbol.iterator. (In ECMAScript Array,
%TypedArray%, Map, and Set have it.) Given HTMLCollection and similar legacy
APIs, getting forEach() needs to be opt-in somehow.

4) I would expect iterable<ScalarValueString, FormDataEntryValue> (no sequenced
value) as a multimap is a list with non-unique keys. (This incidentally makes
it match get() a bit better I suppose. getAll() is for the "weirder" multimap

5) iterable<> should probably imply Symbol.iterator and forEach().

6) FormData seems hard to autogenerate the API for due to the filename
argument. I noticed Headers currently does argument checks even for get() and
has() (should maybe drop that). The way FormData, URLSearchParams, and Headers
work is consistent, but I should probably try to abstract them a bit more
myself first before we try to move logic into IDL for them (if that is even
worth the tax on IDL, there might not be that many multimaps in the end).

You are receiving this mail because:
You are on the CC list for the bug.
Received on Thursday, 2 October 2014 07:22:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:23 UTC