Concern with terms "select" and "reject"
rbuckton opened this issue · 14 comments
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:
- C#, VB (or any other .NET Language)
- SQL-92
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.
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.
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.
Do either of you have an objection to filterOut? Or some variation of filterXYZ where "XYZ" is something like "remove"?
Too long.
.discard?
where and without ?
I think I'd also like where and except.
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.
Just find Kotlin have filter/filterNot methods.
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?
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?
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.
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.
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.