Domenic Denicola wrote:
> 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.
For iteration, sure. For map or other functional (pure?!) APIs? Yikes.
If in ES7 we build up the duality between iterables and observables, add
for-on, pave the way toward FRP, then `map` as a protocol (part) should
be pure with respect to its receiver, ISTM.
> 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.)
More elaborate constructor protocol, but if it's part of maplike, may be ok.
[1]:http://wiki.ecmascript.org/doku.php?id=strawman:bind_operator
Problem is :: vs. just dot, and now you have two problems. I'm actually
good with FP inside-out, could learn to love :: if we add it, but the
main objection IMHO is two-problems. OOP means just dot.
> 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]);
```
Fair, just trying to develop a thought on es-discuss. I'm not sure we
should do anything in TC39 about this. I want future underscore.js
libraries to tread those cowpaths we ultimately pave.
Also the ES7 iterable/observable duality and the DOM maplike demands
combine to push for paving sooner. We should be minimalists as you
suggest, though.
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].
Traits are great -- we lost a live, championed proposal at some point on
the road to ES6. Who will revive?
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
