Re: New Set.prototype methods
I have fixed few minor issues in polyfill, changed wording in Markdown document and submitted files polyfill.js and README.MD as a non-member. I can write formal specification if strawman get any traction. Opinions and any form of feedback are welcome. https://github.com/Ginden/set-methods ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New Set.prototype methods
Methods xor, relativeComplement (aka subtract), addElements, removeElements were added to strawman. Desired signature of method accepting iterables is discussed further in section .union, .intersect, .xor, .relativeComplement desired signature <https://github.com/Ginden/set-methods#union-intersect-xor-relativecomplement-desired-signature> For consistency with Immutable.js it's preferred to allow *multiple iterables*. I will probably change polyfills to reflect this change. https://github.com/Ginden/set-methods Feedback is welcome. On Thu, Jun 2, 2016 at 12:46 AM, Michał Wadas <michalwa...@gmail.com> wrote: > First of all "generic iterator methods" are discussed in this proposal. > Second of all, presence of them isn't incompatible with new methods on Set > instances (discussed in document too). > Third of all, generic iterator methods aren't even proposed, and it's over > two years since I have heard about this idea for first time. > On 2 Jun 2016 12:21 a.m., "Alexander Jones" <a...@weej.com> wrote: > >> 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. <jackalm...@gmail.com> wrote: >> >>> On Sun, May 29, 2016 at 6:13 AM, Michał Wadas <michalwa...@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@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> >> ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New Set.prototype methods
First of all "generic iterator methods" are discussed in this proposal. Second of all, presence of them isn't incompatible with new methods on Set instances (discussed in document too). Third of all, generic iterator methods aren't even proposed, and it's over two years since I have heard about this idea for first time. On 2 Jun 2016 12:21 a.m., "Alexander Jones" <a...@weej.com> wrote: > 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. <jackalm...@gmail.com> wrote: > >> On Sun, May 29, 2016 at 6:13 AM, Michał Wadas <michalwa...@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@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New Set.prototype methods
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. <jackalm...@gmail.com> wrote: > On Sun, May 29, 2016 at 6:13 AM, Michał Wadas <michalwa...@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@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New Set.prototype methods
On Sun, May 29, 2016 at 6:13 AM, Michał Wadas <michalwa...@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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New Set.prototype methods
I've done some work on this (https://github.com/calvinmetcalf/set.up), symmetrical difference, compliment and xor would also be helpful On Sun, May 29, 2016, 9:13 AM Michał Wadas <michalwa...@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) > > %SetIteratorPrototype% is discussed in text. > > BTW, is there any way to subclass SetIterator or check if object is > SetIterator? If not it seems like issue for subclassing Set. > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
New Set.prototype methods
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) %SetIteratorPrototype% is discussed in text. BTW, is there any way to subclass SetIterator or check if object is SetIterator? If not it seems like issue for subclassing Set. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
