New Set methods - again

Peter Jaszkowiak p.jaszkow at gmail.com
Sat Jul 29 01:57:31 UTC 2017


> Out of curiosity, what is the rationale behind the choices for which
non-set-specific, currently-array-only methods to implement?

One rational is that these are also not Array-specific functions either,
and serve as much if not more use with sets than with Arrays. I my
experience, one of the main reasons that people don't use Set and Map is
because they don't have these helpful utility functions.

> For example there is `map`, which saves you one array cast and one set
cast, and `find`, which saves you one array cast, but not, e.g., `reduce`,
which would also save you one array cast.

`reduce` doesn't make sense for Sets because it is an ordered operation.
Sets are unordered, so actually having `forEach` (without the index
parameter) makes more sense than `reduce`.

Having these chainable utility functions on `Set.prototype` will make
dealing with Sets much easier for developers, which will increase their
usage, making proposals for `Array.prototype.union`, etc less relevant.

In my opinion, a lot more attention should be paid to building and
strengthening the standard library of the language instead of adding more
and more syntax.


A couple things I'd like to see added / changed with the proposal, though:

- Why can't `Set.prototype.add` be simply extended to accept multiple
parameters? This would eliminate the need for `addElements`. If
`addElements` is going to be a thing, then it should accept a single
Iterable parameter instead.
- IMO, `forEach` should be added if all of these other functional methods
are, but it should return `this` as opposed to `Array.prototype.forEach`
which returns `undefined`. Alternatively, name it `.each` to signify this
slight semantic difference.
- `.flatMap` would be nice to have, flattening Iterables into the new Set,
and accepting non-iterables as singular values added to the Set
- I imagine that the concerns over `.union`, `.intersect`, etc being slow
when accepting multiple Iterables is avoidable by adding optimizations for
single Sets, multiple Sets, and single iterables

As an aside to this proposal, you mentioned an alternative of adding some
of these methods to `%IteratorPrototype%`. I think both are good ideas, but
the problem is that _really_, only `.map`, `.flatMap`, and `.filter` make
sense with generic Iterators if you want to maintain laziness.


Overall, really good stuff, Michał.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170728/accd1e61/attachment.html>


More information about the es-discuss mailing list