> 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ł.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
