> Note the this.clone() call. This is novel, and required to avoid exhausting
> the receiver iterator.
This is noteworthy and worth keeping in mind regardless of the rest of the
discussion. I think I would be fine having %IterablePrototype%.map exhaust the
iterator. I would `.clone()` manually myself if I didn't want that. But in
general anytime I loop through the iterator---either directly with `for`-`of`,
or indirectly with `.map` and friends---I would expect exhaustion.
> We could just use FP-style map, filter, etc. APIs, but as argued among
> TC39ers, OOP wins in JS: (a) it matches built-ins; (b) it composes left to
> right, not inside out.
I am still hoping [the bind operator][1] gives us a good middle ground. E.g.
```js
import { map } from "js/iterables";
var newMap = oldMap::map(([k, v]) => [k + 1, v + 1]);
```
Here I guess `map` would look something like
```js
function map(...args) {
return new this.constructor(this.entries().map(...args));
}
```
(Note that I use `new this.constructor(entriesIterable)` instead of your `var m
= new this.constructor()` plus `m.set(...)`. Unclear which is better.)
[1]: http://wiki.ecmascript.org/doku.php?id=strawman:bind_operator
> Comments welcome.
My first thought is that it seems a little far out there given that we're
talking about the net benefit being reducing
```js
var newMap = new Map(oldMap.entries().map((([k, v]) => [k + 1, v + 1]);
```
to
```js
var newMap = oldMap.map(([k, v]) => [k + 1, v + 1]);
```
My second thought is that we might also want to consider approaching this from
the perspective of traits, see e.g. [an earlier discussion about Set][2].
But, collections do need some love, so it's good that we're thinking about this.
[2]:
https://esdiscuss.org/topic/overriding-map-etc-with-get-set-hooks#content-54
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
