select! not present but reject! is

G

Geert Fannes

------_=_NextPart_001_01C5C9A3.054922C0
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hello, is there a reason why I can find the in-place mutator method
Array#reject! and not Array#select! ? It is ofcourse easy to add this
method but it is my feeling this should be added to the core.

Greetings,

Geert.


------_=_NextPart_001_01C5C9A3.054922C0--
 
J

Jacob Fugal

Can you use Enumerable#partition ?

That's beside the point, for two reasons:

1) Geert's question is regarding the lack of symmetry between the
presence of Array#reject! but absence of Array#select!.[1]

2) Geert is interested in in-place mutators (Array#reject!,
Array#select!). Enumerable#partition returns two new Arrays; it is not
an in-place mutator.

As far as work-arounds, this would probably be closest:

class Array
def select!
self.reject! { |e| not yield e }
end
end

But I'm sure Geert is already aware of this (or a better version).
Geert's question, to which I would like an answer as well, is this:

Is there a reason Array#select! doesn't exist in the core?

Jacob Fugal
 
D

David A. Black

Hi --

Is there a reason Array#select! doesn't exist in the core?

It seems like a strange concept to me. I don't associate
destructiveness with selecting. I guess there would also be find_all!
which seems even stranger :)

I know one *can* implement it (i.e., I'm not saying I don't know what
it means). I just don't think that in-place removal of items follows
naturally as a ! version of selecting.


David
 
J

Jacob Fugal

Hi --



It seems like a strange concept to me. I don't associate
destructiveness with selecting. I guess there would also be find_all!
which seems even stranger :)

I know one *can* implement it (i.e., I'm not saying I don't know what
it means). I just don't think that in-place removal of items follows
naturally as a ! version of selecting.

Well, maybe select! isn't the right name for it. But as a concept,
including the converse of reject! in the core would make sense, at
least to me. Maybe with a name like Array#keep!, telling ruby which
elements you want to keep and discarding the rest.

Jacob Fugal
 
Y

Yukihiro Matsumoto

Hi,

In message "Re: select! not present but reject! is"

|> Is there a reason Array#select! doesn't exist in the core?
|
|It seems like a strange concept to me. I don't associate
|destructiveness with selecting. I guess there would also be find_all!
|which seems even stranger :)

That is a reason. For the same reason, we didn't implement map!, but
certain number of native speakers persuade me it was not unnatural.
Now we have map! in Array class. Same thing could happen on select!.

matz.
 
R

Rob Rypka

In message "Re: select! not present but reject! is"
|> Is there a reason Array#select! doesn't exist in the core?
|
|It seems like a strange concept to me. I don't associate
|destructiveness with selecting. I guess there would also be find_all!
|which seems even stranger :)

You don't watch enough reality television. The fun of selecting
winners on this week's episode is rejecting everyone else. I also
don't think of reject as non-destructive, but there it is.

I think the exclamation paradigm overrides the subjective connotation
of select and reject. Regardless of whether or not someone uses it in
their own code, I doubt anyone would be confused by the meaning.

Select and reject are perfect compliments. I have, on several
occasions, tried to use select!, but had to rewrite them with reject!
instead (not a difficult transition).

As for find_all!, that's just hard to read (and hard to distinguish
from find_all with many fonts), so I would never use it. Then again,
find_all (regardless of its relationship to select and reject) comes
off as an extension of find, and the correlating find! method would be
silly (although fitting with the reality television metaphor).
That is a reason. For the same reason, we didn't implement map!, but
certain number of native speakers persuade me it was not unnatural.
Now we have map! in Array class. Same thing could happen on select!.

I'll cast my vote for Array#select!, natively speaking.
 
D

David A. Black

Hi --

I think the exclamation paradigm overrides the subjective connotation
of select and reject. Regardless of whether or not someone uses it in
their own code, I doubt anyone would be confused by the meaning.

I'm still not feeling a "dangerous version of select". It seems such
a benign operation :)
Select and reject are perfect compliments. I have, on several
occasions, tried to use select!, but had to rewrite them with reject!
instead (not a difficult transition).

As for find_all!, that's just hard to read (and hard to distinguish
from find_all with many fonts), so I would never use it. Then again,
find_all (regardless of its relationship to select and reject) comes

It's a synonym for select; they call the same method. That's a pretty
hard relationship to disregard :)
off as an extension of find, and the correlating find! method would be
silly (although fitting with the reality television metaphor).

In the middle of writing this I finally got a handle on what bothers
me about select! as (I think) it's being discussed: it's backwards.

If you select! elements from an array (dangerous/destructive select),
those elements should be *removed* from the array. It's like
selecting people from the audience to come onto the stage: they are
removed from the audience. The audience is not reduced to being just
them.

At the same time, the return value of select! should be an array of
the selected items. The ! part would mean: they've been *permanently
selected* (withdrawn from the array).

Here's a whole little testbed for this. In this form it would make
some sense, though I'm still not happy about the find_all! thing....

class Array
def select!
yes,no = partition {|e| yield(e) }
replace(no)
yes
end
end

a = [1,2,3,4]
b = a.reject! {|e| e > 2 }
p a
p b

a = [1,2,3,4]
b = a.select! {|e| e > 2 }
p a
p b

# Output:
[1, 2]
[1, 2]
[1, 2]
[3, 4]


David
 
J

Jacob Fugal

...

In the middle of writing this I finally got a handle on what bothers
me about select! as (I think) it's being discussed: it's backwards.

If you select! elements from an array (dangerous/destructive select),
those elements should be *removed* from the array. It's like
selecting people from the audience to come onto the stage: they are
removed from the audience. The audience is not reduced to being just
them.

Hmm, I'd disagree. After all, we're sending the message to the array
aren't we? I look at it like John the Innocent Array has five apples,
two shiny and three dull. I come along, as the wise programmer, and
say to Johnny, "Johnny, shiny apples are good. You only need to keep
those ones." In Ruby:

johnny =3D []
2.times { johnny << ShinyApple.new }
3.times { johnny << DullApple.new }

# ... later ...

johnny.select! { |a| a.shiny? }

An alternate way to tell this to Johnny would be, "Johnny, shiny
apples are good. You should get rid of any others." In Ruby:

johnny.reject! { |a| not a.shiny? }

However, negating the positive condition (a.shiny?) isn't very
readable. Syntactically, it is really as easy as "not ( condition )",
but if condition is long, it may be confusing to try and keep track of
the ands/ors in condition and then mentally negate it all. Not to
mention that reject! { not } is a double negative, and we all know how
bad those can be (/me temporarily flashes back to second grade...
shudder). Or we can apply DeMorgan's to try and get rid of the not,
but that often muddles the semantics of the condition.

In short, select! is just the converse of reject!, and there's no good
reason not to include it under that context.

Jacob Fugal
 
D

David A. Black

Hi --

Hmm, I'd disagree. After all, we're sending the message to the array
aren't we?

That's true across the board, though; it's not a determinant of what
happens when we send a message.
I look at it like John the Innocent Array has five apples,
two shiny and three dull. I come along, as the wise programmer, and
say to Johnny, "Johnny, shiny apples are good. You only need to keep
those ones." In Ruby:

johnny = []
2.times { johnny << ShinyApple.new }
3.times { johnny << DullApple.new }

# ... later ...

johnny.select! { |a| a.shiny? }

Or you could look at it as: "Give me (permanently) all your shiny
apples!"

my_apples = johnny.select! {|a| a.shiny? }

So now my_apples has them, and johnny doesn't. Mind you, I'm not
eager to see my version in the language either. I don't like the bang
method not returning the receiver. But I don't like the semantics, in
this case, when it does. (And the find_all! thing is a further sign
that this method was not meant to have a bang version.)

I think there's been talk in the past of delete_unless. delete_if is
not quite the same as reject! (one of them returns nil if nothing's
found; the other returns an array, I believe).


David
 
R

Rob Rypka

That's true across the board, though; it's not a determinant of what
happens when we send a message.

But the exclamation mark (to me) says, "Do this to yourself, Mr.
Array." When you tell the array to reject!, it throws away the
matches and says, "Here's my state now, what next?" or "Whoops, I
didn't do anything." I think the same should be applicable for
select.
Or you could look at it as: "Give me (permanently) all your shiny
apples!"

my_apples =3D johnny.select! {|a| a.shiny? }

So now my_apples has them, and johnny doesn't. Mind you, I'm not
eager to see my version in the language either. I don't like the bang
method not returning the receiver. But I don't like the semantics, in
this case, when it does. (And the find_all! thing is a further sign
that this method was not meant to have a bang version.)

Well, I think we should have a Array#gimme and Array#gimme! to
differentiate from select!. Then you would have your functionality,
while select! would say (as I think it should), "select these
(permanently)."

By your logic, reject! is also wrong. johnny.reject! should reject
the items, and then give them to you, which is the same as your
select!. That's not what it does, though...

Regarding find_all!, Just because they're synonyms, doesn't mean they
have to both have the !. If everyone instantly associates select and
find_all together because they're synonyms, why have them both? I
don't think they do. People see 'find' and they think, "But I want to
find everything, not just one," and then they come upon find_all.=20
With select and reject, it says, "pick these," and "pick everything
but these." Just because they end up meaning the same thing, doesn't
mean they have the same connotations.

find and find_all are the benign operations. select and reject are more ri=
sque.
I think there's been talk in the past of delete_unless. delete_if is
not quite the same as reject! (one of them returns nil if nothing's
found; the other returns an array, I believe).

I believe you are correct (about reject! and delete_if, I don't know
about the others).

In all honesty, I don't care what it's called, but reject! feels like
it should have an opposite.
 
W

Wilson Bilkovich

Well, I think we should have a Array#gimme and Array#gimme! to
differentiate from select!. Then you would have your functionality,
while select! would say (as I think it should), "select these
(permanently)."

I vote for Array#winnow
 
D

David A. Black

Hi --

By your logic, reject! is also wrong. johnny.reject! should reject
the items, and then give them to you, which is the same as your
select!. That's not what it does, though...

See my previous post -- it shows the difference (between reject! and
my sense of select!), which is in the return values.
In all honesty, I don't care what it's called, but reject! feels like
it should have an opposite.

Similarly (in case it's unclear), I have no underlying objection to
the idea of a reject! opposite :)


David
 
J

Jacob Fugal

Hi --



See my previous post -- it shows the difference (between reject! and
my sense of select!), which is in the return values.

And that's where it confuses me. select and reject are complements, so
why couldn't it be expected that select! and reject! be complements as
well? Changing the semantics of select from converse of reject without
bang to synonym for reject (differing only in return value) with bang
makes no sense at all to me.
Similarly (in case it's unclear), I have no underlying objection to
the idea of a reject! opposite :)

At least we're all agreed on that. :)

I just fail to see why select should lose it's complementary
relationship with reject when a bang is added. I suggest we retain
that relationship and let select! and reject! remain complementary.
With select and reject we have the following tautology[1]:

def test(ary)
selected =3D ary.select { |e| yield e }
rejected =3D ary.reject { |e| yield e }
rebuilt =3D selected + rejected
(rebuilt - ary).empty? and (ary - rebuilt).empty?
end

I propose select! and reject! should have a similar tautology:

def test(ary)
selected =3D ary.dup.select! { |e| yield e }
rejected =3D ary.dup.reject! { |e| yield e }
rebuilt =3D selected + rejected
(rebuilt - ary).empty? and (ary - rebuilt).empty?
end

Jacob Fugal
 
D

David A. Black

Hi --

And that's where it confuses me. select and reject are complements, so
why couldn't it be expected that select! and reject! be complements as
well? Changing the semantics of select from converse of reject without
bang to synonym for reject (differing only in return value) with bang
makes no sense at all to me.

I completely understand, and I'm the first to admit I've failed to
convey clearly what it is that makes me not feel that the
complementariness carries over to the bang versions, or why I like
"select" for culling elements that pass a test but don't like
"select!" for replacing the array's contents with elements that pass a
test. So I'll have to leave it at that, except that if a brilliant
explanatory model comes to me I'll share it :)


David
 
M

Mark Hubbart

Hi --



See my previous post -- it shows the difference (between reject! and
my sense of select!), which is in the return values.

And that's where it confuses me. select and reject are complements, so
why couldn't it be expected that select! and reject! be complements as
well? Changing the semantics of select from converse of reject without
bang to synonym for reject (differing only in return value) with bang
makes no sense at all to me.
Similarly (in case it's unclear), I have no underlying objection to
the idea of a reject! opposite :)

At least we're all agreed on that. :)

I just fail to see why select should lose it's complementary
relationship with reject when a bang is added. I suggest we retain
that relationship and let select! and reject! remain complementary.
With select and reject we have the following tautology[1]:

def test(ary)
selected =3D ary.select { |e| yield e }
rejected =3D ary.reject { |e| yield e }
rebuilt =3D selected + rejected
(rebuilt - ary).empty? and (ary - rebuilt).empty?
end

I propose select! and reject! should have a similar tautology:

def test(ary)
selected =3D ary.dup.select! { |e| yield e }
rejected =3D ary.dup.reject! { |e| yield e }
rebuilt =3D selected + rejected
(rebuilt - ary).empty? and (ary - rebuilt).empty?
end

The english words "select" and "reject" are not opposites. "reject"
and "keep" might be, as someone else suggested.

Going back, say you have a box of apples, some of which are shiny, the
rest of which are dull. You don't want the dull ones. If you say:

apple_box.reject! {|apple| apple.dull?}

...it sounds like you want to reject, or throw out, any dull apples,
leaving only the shiny ones. The opposite would be:

apple_box.keep! {|apple| apple.shiny?}

...because you want to keep only the shiny ones. "keep" implies that
the rest are not kept, and are thrown out.

On the other hand, if you said:

apple_box.select! {|apple| apple.shiny?}

It implies that you want to keep both; you remove the selected ones
from the box, and leave the unselected ones behind.

Note that your tautology (as written) for select!/reject! works for
this version also. "select!" would return an array of the values
removed from the apple_box.

Also, I'm not really advocating any action here. I'm just suggesting
that it would be a little weird for "select!" to be the exact opposite
of "reject!", since the Ruby definitions wouldn't stand up to the
English ones.

cheers,
Mark
 
J

Jacob Fugal

I just fail to see why select should lose it's complementary
relationship with reject when a bang is added. I suggest we retain
that relationship and let select! and reject! remain complementary.
With select and reject we have the following tautology[1]:

def test(ary)
selected =3D ary.select { |e| yield e }
rejected =3D ary.reject { |e| yield e }
rebuilt =3D selected + rejected
(rebuilt - ary).empty? and (ary - rebuilt).empty?
end

I propose select! and reject! should have a similar tautology:

def test(ary)
selected =3D ary.dup.select! { |e| yield e }
rejected =3D ary.dup.reject! { |e| yield e }
rebuilt =3D selected + rejected
(rebuilt - ary).empty? and (ary - rebuilt).empty?
end

The english words "select" and "reject" are not opposites. "reject"
and "keep" might be, as someone else suggested.

Funny thing is, it was me that suggested 'keep!'. :) But my argument
isn't that "select" and "reject" are necessarily opposites in English,
but that the *existing* non-bang versions of "select" and "reject" in
Ruby *are*.
Going back, say you have a box of apples, some of which are shiny, the
rest of which are dull. You don't want the dull ones. If you say:

apple_box.reject! {|apple| apple.dull?}

...it sounds like you want to reject, or throw out, any dull apples,
leaving only the shiny ones. The opposite would be:

apple_box.keep! {|apple| apple.shiny?}

...because you want to keep only the shiny ones. "keep" implies that
the rest are not kept, and are thrown out.

On the other hand, if you said:

apple_box.select! {|apple| apple.shiny?}

It implies that you want to keep both; you remove the selected ones
from the box, and leave the unselected ones behind.

The English usage of "select" could imply that, and I think that's
what bothers David as well. But, again, my goal isn't consistency with
English (although some of my previous posts in this thread may have
appeared that way), but rather consistency within Ruby. "select" and
"reject" are already direct opposites, so in my mind "select!" and
"reject!" should also be direct opposites.
Note that your tautology (as written) for select!/reject! works for
this version also. "select!" would return an array of the values
removed from the apple_box.

Yes, but this is actually incidental and buggy. I'm of the camp which
prefers any bang method should return either self (for chaining) or
nil. I wouldn't want select!/reject! to return either the selected or
rejected elements. Rather, my example should have been:

def test( ary )
(selected =3D ary.dup).select! { |e| yield e }
(rejected =3D ary.dup).reject! { |e| yield e }
rebuilt =3D selected + rejected
(rebuilt - ary).empty? and (ary - rebuilt).empty?
end

Under David's interpretation of "select!", this function would rarely
return true, whereas I would expect it to always return true.
Also, I'm not really advocating any action here. I'm just suggesting
that it would be a little weird for "select!" to be the exact opposite
of "reject!", since the Ruby definitions wouldn't stand up to the
English ones.

I'll concede that, but IMNSHO consistency between the non-bang and
bang versions seems more important.

Jacob Fugal
 
R

Rob Rypka

Also, I'm not really advocating any action here. I'm just suggesting
that it would be a little weird for "select!" to be the exact opposite
of "reject!", since the Ruby definitions wouldn't stand up to the
English ones.

select and reject (without the exclamation marks) are Ruby opposites,
though. Nobody seems opposed to that.

If I had two methods, Array#foo and Array#foo!, I would expect the
definition of foo! to be:

"Same as Array#foo, but modifies the receiver in place."

Sometimes, the above leads to another (near) synonym (like delete_if
and reject!), but the The return value should be the receiver,
instead of a new array. To me, foo! doesn't mean finding a new
meaning of the foo operation in a way that would be destructive, it
means immediacy to the receiver (which in turn implies destruction).=20
"Select these elements, but alter your contents and return yourself,
instead of someone new."

Anyways, there seems to be enough opposition to select! that Matz
probably isn't going to add it. I give up the fight (even though I
still believe I'm right). I'm going to have to learn to live with
reject!ion (but not select!ion).

Aside: I second the vote for Array#winnow :)
 
R

Rob Rypka

Anyways, there seems to be enough opposition to select! that Matz
probably isn't going to add it. I give up the fight (even though I
still believe I'm right). I'm going to have to learn to live with
reject!ion (but not select!ion).

Jacob and others are free to continue the fight in my pseudo-absense :)
 
D

David A. Black

I'll concede that, but IMNSHO consistency between the non-bang and
bang versions seems more important.

The most important thing, though, is that every method name be
appropriate. If select! ("dangerous select") is the best way to
communicate the "delete unless..." process, then it's right. If not,
then not. It's reasonable to expect that a/b == a!/b! -- but the
existence of a, b, and a! doesn't mean that b! is a good method name
for the inverse of a!.


David
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top