filter/filterNot

[Flavio W. Brasil]

I think that filter/filterNot aren't good names for collections operations. I always get in doubt if they select or reject items.

Would not be better to rename them to "select" (filter) and "reject" (filterNot), like in Smalltalk?

-- 

Flávio W. Brasil

http://activate-framework.org

{persistence as it should be}

[Jiayu Liu]

While I quite agree with you, it's kind of hard to make these changes, and the reason is quite simple: it's just convention, just like P and V in semaphore. Filter is a often seen in other precedent languages like Haskell. 

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Dennis Haupt]

while i agree, i still think there could be 2 methods (select & reject) which just call filter & filternot...
(in my own code, i use a delegate "select" instead of "filter")

Gesendet: Donnerstag, 21. März 2013 um 14:56 Uhr
Von: "Jiayu Liu" <jime...@gmail.com>
An: "Flavio W. Brasil" <fwbr...@gmail.com>
Cc: scala-user <scala...@googlegroups.com>
Betreff: Re: [scala-user] filter/filterNot

[Rex Kerr]

I agree that it's a poor choice for ease of teaching of novices.  Select and reject, along with a variety of others, would be more intuitive.

But it's not hard to remember.  (Alas, there are far too many things each individually easy to remember but collectively difficult.)  And it's essentially impossible to change now (for statements use filter if available, for example).

  --Rex

[Nils Kilden-Pedersen]

On Thu, Mar 21, 2013 at 9:02 AM, Dennis Haupt <h-s...@gmx.de> wrote:

while i agree, i still think there could be 2 methods (select & reject) which just call filter & filternot...

+1
 

[pagoda_5b]

This sounds like a neat solution to me, how about making it to the library?

+1

Ivano

[Pablo Lalloni]

+1

this come up very often when teaching scala collections to others...

El jueves, 21 de marzo de 2013 11:02:46 UTC-3, Dennis Haupt escribió:

while i agree, i still think there could be 2 methods (select & reject) which just call filter & filternot...
(in my own code, i use a delegate "select" instead of "filter")

Gesendet: Donnerstag, 21. März 2013 um 14:56 Uhr
Von: "Jiayu Liu" <jime...@gmail.com>
An: "Flavio W. Brasil" <fwbr...@gmail.com>
Cc: scala-user <scala...@googlegroups.com>
Betreff: Re: [scala-user] filter/filterNot

While I quite agree with you, it's kind of hard to make these changes, and the reason is quite simple: it's just convention, just like P and V in semaphore. Filter is a often seen in other precedent languages like Haskell. 

On Thu, Mar 21, 2013 at 9:21 PM, Flavio W. Brasil <fwbr...@gmail.com> wrote:

I think that filter/filterNot aren't good names for collections operations. I always get in doubt if they select or reject items.

Would not be better to rename them to "select" (filter) and "reject" (filterNot), like in Smalltalk?

-- 

Flávio W. Brasil

http://activate-framework.org

{persistence as it should be}

--
You received this message because you are subscribed to the Google Groups "scala-user" group.

To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Rex Kerr]

Having too many ways to do the same thing ends up adding confusion, not subtracting it, especially when multiple people work on the code.

("Wait, what's select?  Oh, filter.  No, wait...sometimes select is used and sometimes filter...does this mean they're different?  Aaah!")

The appropriate thing to do is add these methods if you really want them for your own code, but otherwise recognize that changing from "filter" to anything else is hugely impractical now.

  --Rex

--

[Nils Kilden-Pedersen]

On Thu, Mar 21, 2013 at 1:01 PM, Rex Kerr <ich...@gmail.com> wrote:

Having too many ways to do the same thing ends up adding confusion, not subtracting it, especially when multiple people work on the code.

This is absolutely true.

Which is why select/reject should be introduced and the compiler using those in for comprehensions, with filter/filterNot deprecated (and removed later).

But that will probably never happen, right?

 

[Haoyi Li]

+1 for multiple ways of doing things adding to the confusion. Some quick googling brings up:

1 Languages using select for this purpose:

- Ruby

2 Languages using select() for what Scala calls map():

- SQL

- C#

3 Languages using filter:

- Haskell

- F#

- Ocaml

- Python

- Javascript

- Java 8?

I'm for sticking with filter, just for consistency with other people. With filter(), the people using group 3 languages will get it instantly, and group 1 and 2 will have to learn it. with select(), the people using group 1 will get it instantly, the people using group 3 will have to learn and the people using group 2 will probably be in for a surprise.

-Haoyi

[Rex Kerr]

I'm not sure about C#, but in SQL SELECT is more of an indexing operation than a map operation.  It's very much like filterKeys on a Scala map (with the keys being the column names).  I expect "WHERE" would be more natural to a SQL user, though, since that is how conditions on rows are specified.  (Anyway, database tables are weird: row-major and column-major operations are duplicated with different names and syntax.)

  --Rex

[Som Snytt]

Don't forget "withSelector".

Personally, I'd have gone with "filterFor" and "filterOut".

There was a discussion not long ago about the sense of the word "cull", meaning "cullect" [sic], which demonstrates a similar ambivalence as to whether the items you cull or collect are the good ones or the bad, but the culls are always the ones you have in hand after culling, so maybe I'll use cull for filter and, thinking of my Brita pitcher, filtered for filterNot.

The dictionary says filter means the "felt" used as a filter.  That also suggests pan: panFor(gold), panOut.

--

[Erik Osheim]

On Thu, Mar 21, 2013 at 11:36:23AM -0700, Som Snytt wrote:
> Personally, I'd have gone with "filterFor" and "filterOut".

Yeah, or even filterInto and filterOut or something.

-- Erik

[Jan Vanek]

I like filterOut too. Having filter and filterOut (i.e. rename filterNot
to filterOut) would be good enough, IMO.

>
> -- Erik
>

[Pablo Lalloni]

Ignoring that "to filter" and "to filter out" are considered synonyms?

AFAICS, the only real issue is that the word "filter" by default has negative connotation as in "remove whatever matches to this predicate" but in tha API it actually means the opposite: "remove whatever doesn't match to this predicate", or, and this is why "select" (positive connotation) is proposed: "take/keep whatever match to this predicate".

filterNot just adds problems... double reversing the meaning of "filter"... it gives a lot to think to newcomers :)

But as others have said... this is very unlikely to change anyway... so we're just wasting time, bandwidth and storage.

--
You received this message because you are subscribed to a topic in the Google Groups "scala-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-user/InI6uM0Rv9c/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to scala-user+unsubscribe@googlegroups.com.

[Nils Kilden-Pedersen]

On Thu, Mar 21, 2013 at 3:35 PM, Pablo Lalloni <plal...@gmail.com> wrote:

Ignoring that "to filter" and "to filter out" are considered synonyms?

AFAICS, the only real issue is that the word "filter" by default has negative connotation as in "remove whatever matches to this predicate" but in tha API it actually means the opposite: "remove whatever doesn't match to this predicate", or, and this is why "select" (positive connotation) is proposed: "take/keep whatever match to this predicate".

filterNot just adds problems... double reversing the meaning of "filter"... it gives a lot to think to newcomers :)

But as others have said... this is very unlikely to change anyway... so we're just wasting time, bandwidth and storage.

For what it's worth, I've talked to Haskell people who feel the same annoyance.

 

On Thu, Mar 21, 2013 at 4:22 PM, Jan Vanek <j3v...@gmail.com> wrote:

On 21.03.2013 19:37, Erik Osheim wrote:

On Thu, Mar 21, 2013 at 11:36:23AM -0700, Som Snytt wrote:

Personally, I'd have gone with "filterFor" and "filterOut".

Yeah, or even filterInto and filterOut or something.

I like filterOut too. Having filter and filterOut (i.e. rename filterNot to filterOut) would be good enough, IMO.

-- Erik

--
You received this message because you are subscribed to a topic in the Google Groups "scala-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-user/InI6uM0Rv9c/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to scala-user+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--

You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.

[Jan Vanek]

On 21.03.2013 21:35, Pablo Lalloni wrote:

Ignoring that "to filter" and "to filter out" are considered synonyms?

AFAICS, the only real issue is that the word "filter" by default has negative connotation as in "remove whatever matches to this predicate" but in tha API it actually means the opposite: "remove whatever doesn't match to this predicate", or, and this is why "select" (positive connotation) is proposed: "take/keep whatever match to this predicate".

filterNot just adds problems... double reversing the meaning of "filter"... it gives a lot to think to newcomers :)

I agree with your points, and I joined the thread only because I too had to inspect the source of filter/filterNot, and the existence of filterNot added significantly to my confusion. On the other hand I don't like select and also reject, I think filter is actually not that bad, apart from the fact that as you say, filter is unlikely to change. I like filterOut because it makes clear that elements which match the predicate will be filtered out, so the existence of filterOut dissolves my small uncertainty about filter, whereas filterNot does not do that job, in fact it does the opposite for me, personally.

But as others have said... this is very unlikely to change anyway... so we're just wasting time, bandwidth and storage.

On Thu, Mar 21, 2013 at 4:22 PM, Jan Vanek <j3v...@gmail.com> wrote:

On 21.03.2013 19:37, Erik Osheim wrote:

On Thu, Mar 21, 2013 at 11:36:23AM -0700, Som Snytt wrote:

Personally, I'd have gone with "filterFor" and "filterOut".

Yeah, or even filterInto and filterOut or something.

I like filterOut too. Having filter and filterOut (i.e. rename filterNot to filterOut) would be good enough, IMO.

-- Erik

--
You received this message because you are subscribed to a topic in the Google Groups "scala-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-user/InI6uM0Rv9c/unsubscribe?hl=en.

To unsubscribe from this group and all its topics, send an email to scala-user+...@googlegroups.com.

[Nils Kilden-Pedersen]

On Thu, Mar 21, 2013 at 4:12 PM, Jan Vanek <j3v...@gmail.com> wrote:

On 21.03.2013 21:35, Pablo Lalloni wrote:

Ignoring that "to filter" and "to filter out" are considered synonyms?

AFAICS, the only real issue is that the word "filter" by default has negative connotation as in "remove whatever matches to this predicate" but in tha API it actually means the opposite: "remove whatever doesn't match to this predicate", or, and this is why "select" (positive connotation) is proposed: "take/keep whatever match to this predicate".

filterNot just adds problems... double reversing the meaning of "filter"... it gives a lot to think to newcomers :)

I agree with your points, and I joined the thread only because I too had to inspect the source of filter/filterNot, and the existence of filterNot added significantly to my confusion. On the other hand I don't like select and also reject,

It could be any number of alternatives, e.g. include/exclude, keep/toss, etc.

 

I think filter is actually not that bad, apart from the fact that as you say, filter is unlikely to change. I like filterOut because it makes clear that elements which match the predicate will be filtered out, so the existence of filterOut dissolves my small uncertainty about filter, whereas filterNot does not do that job, in fact it does the opposite for me, personally.

But as others have said... this is very unlikely to change anyway... so we're just wasting time, bandwidth and storage.

On Thu, Mar 21, 2013 at 4:22 PM, Jan Vanek <j3v...@gmail.com> wrote:

On 21.03.2013 19:37, Erik Osheim wrote:

On Thu, Mar 21, 2013 at 11:36:23AM -0700, Som Snytt wrote:

Personally, I'd have gone with "filterFor" and "filterOut".

Yeah, or even filterInto and filterOut or something.

I like filterOut too. Having filter and filterOut (i.e. rename filterNot to filterOut) would be good enough, IMO.

-- Erik

--
You received this message because you are subscribed to a topic in the Google Groups "scala-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-user/InI6uM0Rv9c/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

You received this message because you are subscribed to the Google Groups "scala-user" group.

To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.

[Oliver Ruebenacker]

Hello,

On Thu, Mar 21, 2013 at 5:41 PM, Nils Kilden-Pedersen <nil...@gmail.com> wrote:
>
>
> On Thu, Mar 21, 2013 at 4:12 PM, Jan Vanek <j3v...@gmail.com> wrote:
>>
>> On 21.03.2013 21:35, Pablo Lalloni wrote:
>>
>> Ignoring that "to filter" and "to filter out" are considered synonyms?
>>
>> AFAICS, the only real issue is that the word "filter" by default has
>> negative connotation as in "remove whatever matches to this predicate" but
>> in tha API it actually means the opposite: "remove whatever doesn't match to
>> this predicate", or, and this is why "select" (positive connotation) is
>> proposed: "take/keep whatever match to this predicate".
>>
>> filterNot just adds problems... double reversing the meaning of
>> "filter"... it gives a lot to think to newcomers :)
>>
>>
>> I agree with your points, and I joined the thread only because I too had
>> to inspect the source of filter/filterNot, and the existence of filterNot
>> added significantly to my confusion. On the other hand I don't like select
>> and also reject,
>
>
> It could be any number of alternatives, e.g. include/exclude, keep/toss,
> etc.

keepIf/tossIf

Take care
Oliver

--
IT Project Lead at PanGenX (http://www.pangenx.com)
The purpose is always improvement

[Som Snytt]

On Thu, Mar 21, 2013 at 2:45 PM, Oliver Ruebenacker <cur...@gmail.com> wrote:

On Thu, Mar 21, 2013 at 5:41 PM, Nils Kilden-Pedersen <nil...@gmail.com> wrote:
> On Thu, Mar 21, 2013 at 4:12 PM, Jan Vanek <j3v...@gmail.com> wrote:
>>
>> On 21.03.2013 21:35, Pablo Lalloni wrote:
>>
>> Ignoring that "to filter" and "to filter out" are considered synonyms?

We filter water but we filter out impurities.
 

>
>
> It could be any number of alternatives, e.g. include/exclude, keep/toss,
> etc.

  keepIf/tossIf
   

Canonically, partition._1 and partition._2.

Or is it the other way around?

This is why so many babies are tossed out with the bath water.

[Rex Kerr]

On Thu, Mar 21, 2013 at 5:41 PM, Nils Kilden-Pedersen <nil...@gmail.com> wrote:

On Thu, Mar 21, 2013 at 4:12 PM, Jan Vanek <j3v...@gmail.com> wrote:

On 21.03.2013 21:35, Pablo Lalloni wrote:

Ignoring that "to filter" and "to filter out" are considered synonyms?

AFAICS, the only real issue is that the word "filter" by default has negative connotation as in "remove whatever matches to this predicate" but in tha API it actually means the opposite: "remove whatever doesn't match to this predicate", or, and this is why "select" (positive connotation) is proposed: "take/keep whatever match to this predicate".

filterNot just adds problems... double reversing the meaning of "filter"... it gives a lot to think to newcomers :)

I agree with your points, and I joined the thread only because I too had to inspect the source of filter/filterNot, and the existence of filterNot added significantly to my confusion. On the other hand I don't like select and also reject,

It could be any number of alternatives, e.g. include/exclude, keep/toss, etc.
 

Indeed; I've used keep/toss before--overloaded to be both filter/Not and take/drop.

Besides, then you can use keepRight :)

  --Rex

[Rex Kerr]

On Thu, Mar 21, 2013 at 6:58 PM, Som Snytt <som....@gmail.com> wrote:

On Thu, Mar 21, 2013 at 2:45 PM, Oliver Ruebenacker <cur...@gmail.com> wrote:

On Thu, Mar 21, 2013 at 5:41 PM, Nils Kilden-Pedersen <nil...@gmail.com> wrote:
> On Thu, Mar 21, 2013 at 4:12 PM, Jan Vanek <j3v...@gmail.com> wrote:
>>
>> On 21.03.2013 21:35, Pablo Lalloni wrote:
>>
>> Ignoring that "to filter" and "to filter out" are considered synonyms?

We filter water but we filter out impurities.
 

>
>
> It could be any number of alternatives, e.g. include/exclude, keep/toss,
> etc.

  keepIf/tossIf
   

Canonically, partition._1 and partition._2.

implicit class PartitionedPair[A](val aa: (A,A)) extends AnyVal {
  def kept = aa._1
  def lost = aa._2
}

scala> List(1,2,3).partition(_ % 2 == 0).kept
res1: List[Int] = List(2)

Now, if only partition would return one of these.

  --Rex