New Set.prototype methods

Alexander Jones alex at weej.com
Wed Jun 1 22:21:28 UTC 2016


Most of these would be better off as generic iterable-consuming,
iterator-producing functions. You know, Single Responsibility Principle,
and all that.

As for the rest, IMO union, intersect, and the zoo of other missing set
theory operators would probably be better off as multiple dispatch
functions, as either operators or unified call syntax... I think I've seen
proposals for all of those floating around.

On 1 June 2016 at 00:38, Tab Atkins Jr. <jackalmage at gmail.com> wrote:

> On Sun, May 29, 2016 at 6:13 AM, Michał Wadas <michalwadas at gmail.com>
> wrote:
> > I have written proposal for new Set.prototype methods.
> >
> > https://github.com/Ginden/set-methods
> >
> > New methods would be:
> >
> > Set.prototype.filter
> > Set.prototype.map
> > Set.prototype.some
> > Set.prototype.every
> > Set.prototype.find
> > Set.prototype.union
> > Set.prototype.intersect
> > Set.isSet
> >
> >
> > TBA:
> >
> > Set.prototype.difference (or .except)
>
> Yes *please* to all of these.  I've added most of them manually to
> Set.prototype on some of my projects.
>
> One additional request in a related vein - Set.prototype.chain - like
> .map, but the callback's value is iterated and added to the result
> set.  (We need to coordinate this with an identical method on Array;
> .chain just seems to be one of the more common names for this
> operation in JS-land.)  I use this a *lot* to, for example, expand
> items into related terms.
>
> ~TJ
> _______________________________________________
> 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/20160601/b4608455/attachment-0001.html>


More information about the es-discuss mailing list