Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Concern with terms "select" and "reject" #6

Open
rbuckton opened this issue Dec 5, 2019 · 14 comments
Open

Concern with terms "select" and "reject" #6

rbuckton opened this issue Dec 5, 2019 · 14 comments

Comments

@rbuckton
Copy link

rbuckton commented Dec 5, 2019

select

While there are some languages where term select is synonymous with ECMAScript's filter (i.e. Ruby), there are other languages where the term select is synonymous with ECMAScript's map:

As a heavy user of both C# and T-SQL (a SQL-92 derivative), I would find the term confusing. In the languages above, as well as other languages such as XQuery, the term where is often synonymous with ECMAScript's filter instead.

reject

I find the use of reject here a possible source of confusion as the term is overloaded with Promise.reject.

While I don't necessary find the use case for an alias of filter compelling, if we did choose to add an alias then I might suggest some less ambiguous terms such as where/whereNot or where/exceptWhere for these two member names.

@hax
Copy link
Member

hax commented Dec 5, 2019

I agree that reject will cause confusion with Promise.reject, especially for the programmers who have very bad English level, most of them remember the api names by rote learning. It cost them long time to create mapping from symbol "reject" to concept "promise rejection" in their mind. "Overloading" the name for very different concept require them to split the original one-to-one mapping to one-to-two mapping.

Though "overloading" is inevitable in many cases (for example, MM mentioned Map.set, Set.map, Map.map 😂 in the meeting), I really hope we'd better avoid it if possible.

@rbuckton
Copy link
Author

rbuckton commented Dec 5, 2019

My main point is that if a primary motivator of this proposal is to reduce developer confusion, then a requirement should be that whatever names are chosen do not introduce additional confusion.

@jridgewell
Copy link
Member

Do either of you have an objection to filterOut? Or some variation of filterXYZ where "XYZ" is something like "remove"?

@zloirock
Copy link
Contributor

zloirock commented Dec 6, 2019

Too long.

@zloirock
Copy link
Contributor

zloirock commented Dec 6, 2019

.discard?

@haltcase
Copy link

haltcase commented Dec 7, 2019

where and without ?

I think I'd also like where and except.

@hax
Copy link
Member

hax commented Dec 19, 2019

Personally I feel filterXXX is better than other options because it's easy to recongnize the connection with filter method, and may also make filter a litter bit clear.

.discard sounds like a mutate method.

@hax
Copy link
Member

hax commented Jan 17, 2020

Just find Kotlin have filter/filterNot methods.

@stanleyxu2005
Copy link

stanleyxu2005 commented Jan 19, 2020

The word filter is neutral. Indeed it is confusing. The beauty of language is simplicity. The best example is Math. Introducing more functions (or aliases) will just make things even more complicated.

Okay, if we do want to suggest better names, I'd vote for pick. It means to pick elements as a new array from existing array with particular criteria.

There is indeed no need to have an opposite method, people can negate values with the original one, cannot they?

@jridgewell
Copy link
Member

Okay, if we do want to suggest better names, I'd vote for pick. It means to pick elements as a new array from existing array with particular criteria.

The committee has rejected adding an alias. We'll only get new functions, if anything.

There is indeed no need to have an opposite method, people can negate values with the original one, cannot they?

I think the data shows people want to use an inverse.

Additionally, this kind of reasoning would prevent us from getting basically any new APIs. Why have forEach/map/filter/some/every when you can just do reduce?

@schmod
Copy link

schmod commented Jan 22, 2020

One concern I have is that "filter out" feels like an English-specific idiom that won't translate well into other languages.

.omit and .without are both vocabulary words with a narrower definition, and less potential ambiguity. Failing that, something like .filterNot (while awkward to say) seems like it would be more comprehensible to an international audience.

@jridgewell
Copy link
Member

One concern I have is that "filter out" feels like an English-specific idiom that won't translate well into other languages.

Yes, I agree that's a concern. It'd probably be good to get input from a non-native English speaker.

.omit and .without are both vocabulary words with a narrower definition, and less potential ambiguity. Failing that, something like .filterNot (while awkward to say) seems like it would be more comprehensible to an international audience.

I would really like to keep the filterXYZ form, so that filter and filterXYZ become obviously associated with one another. filterOut, filterOmit, filterWithout, etc, are all acceptable forms to me.

My only issue with filterNot is that it doesn't help with my confusion about which one does what. If I assume that filter "removes" items, then filterNot seems to "keep" items. It's not obvious from the name alone which does what.

So I'd like to limit it to any "XYZ" that implies removal.

@Andrew-Cottrell
Copy link

Andrew-Cottrell commented Jun 5, 2020

I think the data shows people want to use an inverse.

Trying to find an opposed or inverse term for the verb 'to filter' feels like the wrong approach. This proposal seems to want a method that filters (verb), but with the negation or inverse of the specified filter (noun). This is confusing because the name Array#filter uses filter as a verb and the supplied boolean-valued function implements a filter (noun).

A filter doesn't actively select, reject, keep, or discard items. A filter is more passive than those terms imply. When actively filtering (verb) one or more items, each item either passes through the filter (noun) or doesn't. The Array#filter method is not the filter, rather it is responsible for actively filtering items through the supplied passive filter, implemented by a boolean-valued function. The filter then evaluates to true for items that pass through or to false for items that do not pass through. Naturally, the Array#filter method accumulates and eventually returns those items that pass through the filter. It does not remove items from or keep items within the array it is called upon; it doesn't modify that array at all.

Perhaps what I've stated is obvious to everyone, or alternatively it may be debatable, and please accept my apologies if anyone finds it contentious. But I think it suggests lucid documentation, written for a general audience, with diagrams and perhaps animations — and in terms of Array#filter filtering items through a filter that each item might pass through — may reduce the perceived need for the proposed method.


It might be useful to have a method that evaluates to the negation of a boolean-valued function

var odd = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9].filter( Function.negation( n => n % 2 === 0 ) );

It occurs to me that Array#filter, as it both filters and collects the filtrate, could be named Array#collectFiltrate in another universe. In that same universe, an opposed method might be named Array#collectResidue. I doubt that name would be popular in our universe.


The terms filterIn and filterOut are too similar to filterInput and filterOutput, which are common operations that don't imply collection of the residue. For that reason I think they would be inappropriate.

@dscotese
Copy link

I'd like to suggest adding an alias for Array.filter called Array.keep. I agree with the problem of using "reject" to invert Array.filter. I want to suggest Array.remove. Since delete doesn't actually remove the element, but just replaces it with undefined, it would be handy to have an Array.remove function that actually returns an array with fewer indices and uses semantically clear English. While we can't switch the semantics of filter, we can add the alias with sound semantics (keep), add an explicit inverse (remove), and eventually drop filter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants