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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26183

--- Comment #3 from Domenic Denicola <domenic@domenicdenicola.com> ---
### Definitely do this

ArrayLikeIterable => keys(), values(), entries(), [Symbol.iterator](), forEach,
all === to their Array.prototype counterparts. (Assumes the host interface
defines a .length property)

Should require nothing from the author besides being zero-indexed and having a
length. As we get proper Array subclasses, this should disappear; it's mostly
for slapping onto older interfaces.

### Needs some thought

MapLikeIterable => keys(), values(), entries(), [Symbol.iterator](), forEach,
with key-value semantics.

Spec authors need to define some kind of abstract ordered list of key-value
pairs these can work off of. The ES6 spec formalizes this as an ECMASpeak List
of ECMASpeak Records {[[key]], [[value]]}, with the additional wrinkle that it
represents deletions as setting the key to `empty` in sans-serif font. That's
kind of lame, but we do need spec authors to be rigorous somehow.

I think spec authors should separately define size, if they want it? Or we
could assume they want it, and if we find a case where they don't, we can
define MapLikeIterableNoSize

### Unsure

SetLikeIterable => like MapLikeIterable, but with the (admittedly weird) set
semantics where keys and values are the same, and entries are just [v, v]
arrays.

Do we have any use case for this?

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

Received on Wednesday, 27 August 2014 20:23:13 UTC