Alias problem

[shilangyu]

While I agree that the filter method is very confusing, a thing I would hate more is having aliases. Array.prototype.filter will most likely not be removed/deprecated when select will make its way into JavaScript. Which will mean we will have 2 1:1 methods. My 2 cents are that I support this proposal only if it will ensure that programmers wont have to choose between filter and select.

[edongashi]

In .NET's LINQ enumerable.Select(x => ...) means a projection (Array.map). People coming from C# would certainly be confused.

[jridgewell]

Which will mean we will have 2 1:1 methods. My 2 cents are that I support this proposal only if it will ensure that programmers wont have to choose between filter and select.

I think this falls into a linter concern. Certainly seeing mixed use of .filter and .select isn't ideal, but but giving people the option to choose .select is worth it to both the writer and reader.

Note that we have other aliases already in the language:

• Set.prototype.keys is an alias of Set.prototype.values
• String.prototype.trimLeft is an alias of String.prototype.trimStart
• String.prototype.trimRight is an alias of String.prototype.trimEnd

(That's not including the aliases from the @@iterator to some other method)

[ljharb]

To be fair tho, in the first case, that’s because the protocol requires all three of keys/values/entries; in the second two, that’s because the right/left variants were impossible to remove, and ended up effectively deprecated, in annex b.

I don’t think any of those three serves as precedent for this proposal.

[hax]

Maybe only add Array.p.filterOut ?

[jridgewell]

that’s because the right/left variants were impossible to remove, and ended up effectively deprecated, in annex b.

Annex B doesn't mean deprecated.

Maybe only add Array.p.filterOut ?

That's another possibility, but it doesn't help with filter doing the opposite of what it should.

[hax]

it doesn't help with filter doing the opposite of what it should

With both filter/filterOut in IDE's autocomplete list , I guess the programmers may reason out they will have opposite behavior... 😂

[jridgewell]

in IDE's autocomplete list , I guess the programmers may reason out they will have opposite behavior... 😂

And when reading, when there's no autocomplete list? Or people who just use and editor and not and IDE (like me)?

[ljharb]

Annex B means many potential things; absolutely one of them is “deprecated”.

[ckknight]

I love the idea of a reject method on Array.prototype. Or it could be called filterOut or any other name that makes sense and fits within our existing ecosystem.

The select name makes sense if one comes from a Ruby background, but does not if one comes from a LISP, .NET, Java, or SQL background.

One potential issue I see with reject is that Array.prototype.reject is very different from Promise.reject despite sharing the same name. It could lead to some confusion.

As an aside, if we add reject, it might be appropriate to add partition that could act similarly to https://lodash.com/docs/4.17.15#partition — this also might be out-of-scope.

[MaxGraey]

yeah, I also thought about partition. But it seems this out of scope: #2

[jridgewell]

LISP, .NET, Java, or SQL

I know what SELECT does in SQL, but how about the other languages?

[MaxGraey]

For example in LINQ (C#) Select is analog of Array.p.map.

[jridgewell]

Yah, the C# one was mentioned in #1 (comment).

But Java? I'm not aware of a similarly named method. And I know nothing about LISP.

[motss]

I really like this idea. So I've added it to one of my packages jsmodern for TypeScript users (deno users should never miss this).

[jdalton]

Just popping in to register my dislike of an alias. I'm in favor of reject (or filterOut, or whatever the final name is) though 👍