New Set methods - again

Peter Jaszkowiak p.jaszkow at gmail.com
Sat Jul 29 07:01:43 UTC 2017


Yes I realised that right after sending the reply. Don't know what I was
thinking before.

On Jul 29, 2017 00:45, "Jordan Harband" <ljharb at gmail.com> wrote:

> Set and Map both already have forEach, and both return undefined, just
> like Array.prototype.forEach.
>
> On Fri, Jul 28, 2017 at 6:57 PM, Peter Jaszkowiak <p.jaszkow at gmail.com>
> wrote:
>
>> > 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
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170729/3c383bc5/attachment-0001.html>


More information about the es-discuss mailing list