iterable's should have more than just forEach()

[marcoscaceres]

iterable declarations adds.forEach() method to an interface, which is nice... however, only having forEach is too limited - would be great if iterable declarations got all the useful Array methods, like .reduce(), .find(), etc.

[annevk]

It's more than forEach():

In the ECMAScript language binding, an interface that is iterable will have entries, forEach, keys, values, and @@iterator properties on its interface prototype object.

But yeah, it's worth investigating if we can add more.

[bzbarsky]

This has come up a few times.

Realistically, this is why I supported [ArrayClass]: you get all the generic array things for free.... Anyway, we could have iterable declarations pull in Array.prototype.find onto the relevant prototype and that would work fine, I think. And we could do similar for others, and keep whacking the moles as ES gets updated.

[bzbarsky]

Even nicer would be if ES had facilities for doing this stuff by default on anything that has keys/values/@@iterator, because then it would Just Work. But the current facility for it is Array.prototype.find.call(myObj, stuff) which is not terribly ergonomic.

[TimothyGu]

Or [...myObj].find(stuff), which doesn't look too bad… (No opinion, just an observation.)

[bzbarsky]

That one is pretty inefficient, though.

[annevk]

The main reason we removed [ArrayClass] is that tagging it on things we wanted it for, e.g., NodeList, wasn't web-compatible. And for new lists we generally want folks to return arrays.

So therefore our options seem to be:

1. Accept the inefficiency and slight inelegance of [...obj].find(callback) (and perhaps try to optimize it if it becomes a pattern).
2. See if TC39 is interested is interested in a more elegant and efficient API for objects that have @@iterator. @domenic might know this?
3. Test which Array properties we can add to IDL iterators without breaking the web and add them.

[marcoscaceres]

For 1, it's definitely already a pattern (with Array.from(), presumedly because Edge only just got full iterator support for NodeList): see sample query on github.

[domenic]

IMO if you want an array, you should not be using iterable<>. You should be using an array. iterable<> is when you need to create some completely custom collection, e.g. DOMTokenList (a type of set), URLSearchParams (a multi-map), or when you need to adapt legacy array-likes.

[annevk]

@domenic it's not clearly stated in OP, but the goal of this discussion is to improve NodeList and other "legacy" interfaces that have no way out and are returned aplenty.

[marcoscaceres]

@annevk thanks for clarifying the intent.

I agree with @domenic that an iterable is not an Array. I'm also sympathetic that we can't get NodeList to extend Array, as it will probably break the web.

What is clear is that developers want an array-like - so maybe @bzbarsky's whack-a-mole solution (#561 (comment)) could work with maybe a [ArrayMethods] or some kind of mixin that has map(), filter(), reduce() etc.

[annevk]

As per #561 (comment) we'll have to test those properties individually as we know adding all of them breaks the web.

[marcoscaceres]

Sure, agree. Is there precedent for how we go about testing this web compat?

[bzbarsky]

Was the we breakage from properties, or from instanceof Array?

[annevk]

I don't remember.

[marcoscaceres]

Maybe something about NodeList being a live collection?

[bzbarsky]

I looked it up: the specific compat issue was people doing .concat() on nodelists because they tested true for instanceof Array. So nodelists that were ArrayClass and implemented @@isConcatSpreadable would not have had the one known compat issue.

The real issue was that no one except Gecko was interested in implementing [ArrayClass]...

[tabatkins]

IMO if you want an array, you should not be using iterable<>. You should be using an array. iterable<> is when you need to create some completely custom collection, e.g. DOMTokenList (a type of set), URLSearchParams (a multi-map), or when you need to adapt legacy array-likes.

Or when you want something that looks like an Array but actually implements the same sort of typechecking that every single other object in WebIDL is allowed to implement...

[saschanaz]

I hope the ES array methods (edit: optionally) use Symbol.iterator rather than requiring length property. Doing that will at least ease writing a helper library without a need to rewrite everything.

[bzbarsky]

I hope the ES array methods (edit: optionally) use Symbol.iterator rather than requiring length property

Which methods?

Generally speaking, the Array generics in ES in fact use the length property; they were mostly designed before iterators existed and were meant to work on arbitrary arraylikes.

[saschanaz]

Which methods?

Nearly all, except push() and pop() which won't work with iterators, so that this can just work:

Array.prototype.find.call(iterableWithoutLength, fn); // does not creates a new array

[bzbarsky]

https://tc39.github.io/ecma262/#sec-array.prototype.find gets the .length and then walks from 0 to that length.