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


--- Comment #21 from Cameron McCormack <cam@mcc.id.au> ---
(In reply to Anne from comment #20)
> 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.

But once the iterable<> text is written up this would no longer be needed? 
It's possible in the future we might need to pass around iterator objects (and
what to use an "iterator" type in interface member declarations), but I'd
rather wait until we see we need it.

> 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.

OK.  Is distinguishing between "iterator;" and "iterable<>" (gosh this is going
to be confusing, suggestions welcome) enough for determining whether to have a

> 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 view.)

OK, I'll ensure the internal map data supports non-unique keys, but have the
default set() on maplikes avoid adding duplicates.  (Which could then be
overridden if a spec needed to.)

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

I think I mentioned the former.  Ack for the latter.

> 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).

All right let's just start with iterable<> for FormData and co.

You are receiving this mail because:
You are on the CC list for the bug.

Received on Thursday, 2 October 2014 08:22:10 UTC