While map is a great name, I always struggle to remember if ‘filter’ keeps elements that match the condition or removes them.
I mean, it’s like a colander: you filter noodles and water, but which one do you keep? The noodles, right? But, replace noodles with tea and now you want to keep the water part.
Naming is hard I guess.
C++ std::remove.
I would never have guessed what it does exactly. (It moves elements that match the filter to the front, and moves the end-marker forward. Leaves all the elements in the collection. You need to erase them yourself. )
bsnpApproved := tvShows reject: [ :eachShow | eachShow hasNaughtyContent ].
(It also has remove-if-not but that's deprecated and if you use it your code smells.)
Scheme has `filter` and `filter-not` in the SRFI-1 list library. Both of which can easily be written using a fold to bring this vaguely on topic.
I suspect the reason the function was deprecated was its naming, nothing more; had it been called retain-if or keep-if, it would not have attracted deprecating attention.
The smell added to your code is just the double-negative name of that function, not what it's doing for you.
The name filter smells even more. Is that filtering for items that match? Or filtering out?
In physical filters, sometimes the filtrate is considered the payload output (that which passes through the filter) and sometimes the retentate (that which is caught in the filter).
keep-if is readable.
As for deprecation, IIRC the '-if-not' functions were deprecated because the committee felt the 'complement' function accomplished that task better.
Edit: My IIRC seems largely correct. More detail at
https://www.lispworks.com/documentation/HyperSpec/Issues/iss...
If you want keep-if, you don't want to use a different function, which forces you to complement your predicate. If you want (keep-if #'redp jellybean-list) to keep the red jelly beans, you don't want to write (remove-if (complement #'not-red-p) jellybean-list). If keep-if has a silly name remoe-if-not, you might nonetheless prefer (remove-if-not #'redp jelly-bean-list).
Shims like complements are ugly, and compilers won't optimize through them for arbitrary function definitions (whose source code is not even in scope), so it is good to have both keepers and removers. Heck, it's useful to have a function which does both in one pass returning two values: the filtrate and the retentate.
In Common Lisp both functions exist, under the names `remove-if` and `remove-if-not`.
I think since we have a pair of them and reject is so obvious it helps me remember which way filter works.
I think Enum.keep and Enum.reject might be a better pair, but I've used them enough to internalize it now
And it's a doubly-good analogy, because I have occasionally gotten that confused in real-life as well. Twice in the past ten years I've had a stock boil away for three hours, and then set a colander in the sink and poured it through, only to watch my beautiful stock swirl down the drain because motor-memory made me forget that I wasn't draining pasta but should have put the colander in a bowl...
> I always struggle to remember if ‘filter’ keeps elements that match the condition or removes them
`filter(where:)` like in swift...?
what about `exclude()` or `keep()`?
in those cases its less ambiguous (to me anyways) that returning true means 'yes' to 'keep' or 'exclude', whereas saying yes or no to filter is like 'filter to exclude or include?'
thats my take anyway