Prototype as independent npm package for feedback?

[littledan]

I think it'd be great if, prior to Stage 2 (or at least Stage 3), this could be prototyped as an independent package on npm, so we can get some real-world feedback on how people like it.

IMO, it would be best to do this as a module exporting these two things as functions, rather than monkey-patching onto the Array.prototype, for the reasons described in Andrew Betts' essay Polyfills and the evolution of the Web.

Even if similar features are available elsewhere, and we have a good understanding from that experience that it would be a good idea, this prototype may give us some more data on the details we select in this proposal.

[zloirock]

I'm not a fan of .select, so I don't want to add it before the next stage to core-js.

[littledan]

I'd actually recommend making this a separate package until it becomes Stage 3 or 4. Putting this into core-js and monkey-patching the built-ins risks making it harder for us to iterate on changes.

[zloirock]

I don't think that adding it to core-js could cause any serious problems since it could be added as a proposal, not to the standard subset of features and could not cause any serious problems with the current core-js policy about breaking changes (only in major releases) since I don't see any serious possible changes in the spec text, but I'm too skeptical about adding an alias to .filter - for me and many other users .select alias is even more non-obvious.

[littledan]

Well, lots of project maintainers have explicitly said that they don't guarantee stability over certain time periods, and then the JS spec ends up being held back due to wide deployment anyway--Mootools is a classic example. But this is a bigger discussion independent of Array.prototype.select/reject that we should discuss elsewhere.

[zloirock]

For this case is no difference is it a big project from which you could optionally include this polyfill or a small independent package. core-js tries to prevent possible related problems, however, completely prevent them is not possible. Definitely, it's should be discussed in another place.

[jridgewell]

it would be best to do this as a module exporting these two things as functions

These already exist as lodash/underscore functions, and data is at https://github.com/jridgewell/proposal-array-select-reject/issues/4. Note lodash no longer has _.select, but it's easy enough for an aliased import: import select from 'lodash.filter', though I don't imagine many would do that since "filter" is the official name.

rather than monkey-patching onto the Array.prototype

I think that would hamstring the data. Ease of use is required here, and swapping from functional to prototype is a nuisance:

const array = select(
  input.map(e => e.value),
  (value) => predicate(value)
).find(value => match(value))

this prototype may give us some more data on the details we select in this proposal.

The only details for this proposal is the name, though. select (or any name we choose) must be implemented the same as filter, and reject (or filterOut) must be the opposite of filter's predicate.

[littledan]

These already exist as lodash/underscore functions, and data is at #4.

Array.prototype.reject is a bit different from _.reject in its semantics, so I'm not sure if it's really comparable.

I think that would hamstring the data.

So, because it would be an unfair disadvantage, you're suggesting that we use other kinds of evidence to decide without direct experience? Maybe that could work with these very small proposals, but I don't think it's a good idea for standard library features most of the time.

[jridgewell]

Array.prototype.reject is a bit different from _.reject in its semantics, so I'm not sure if it's really comparable.

The object filtering?

So, because it would be an unfair disadvantage, you're suggesting that we use other kinds of evidence to decide without direct experience?

I'm suggesting that I would just make a prototype polyfill, if anything. But I doubt people will install either version. They'll just use lodash's functions, or they'll stick to the "official" method and change their predicate to match what's needed.

Maybe that could work with these very small proposals, but I don't think it's a good idea for standard library features most of the time.

I don't think there is any data to collect here. I'm proposing an alias, and an opposite behavior of an already spec'd feature. The proposal's spec won't change, only the naming.

We can certainly bikeshed the naming with everyone, but I don't think that's going to be useful. I've chosen the names with precedent in the ecosystem.

[hax]

Ease of use is required here, and swapping from functional to prototype is a nuisance

Totally agree with that! This is a very important issue and apply to all proposals relate to prototype methods/accessors. I really hope we can revive bind operator which can help to solve "how to experiment and get real feedback for prototype methods" issue.