select! not present but reject! is
 

------_=_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--

Re: select! not present but reject! is
 

Can you use Enumerable#partition ?

Geert Fannes wrote:
> 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.

Re: select! not present but reject! is
 

On 10/5/05, Gene Tani <gene.tani@gmail.com> wrote:
> Can you use Enumerable#partition ?
>
> Geert Fannes wrote:
> > 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.

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

Re: select! not present but reject! is
 

Hi --

On Thu, 6 Oct 2005, Jacob Fugal wrote:

> 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

--
David A. Black
dblack@wobblini.net

Re: select! not present but reject! is
 

On 10/5/05, David A. Black <dblack@wobblini.net> wrote:
> Hi --
>
> On Thu, 6 Oct 2005, Jacob Fugal wrote:
>
> > 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.

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

Re: select! not present but reject! is
 

Hi,

In message "Re: select! not present but reject! is"
on Thu, 6 Oct 2005 06:47:35 +0900, "David A. Black" <dblack@wobblini.net> writes:

|> 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.

Re: select! not present but reject! is
 

On 10/6/05, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
> In message "Re: select! not present but reject! is"
> on Thu, 6 Oct 2005 06:47:35 +0900, "David A. Black" <dblack@wobblini.=
net> writes:
>
> |> 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.

--
Rob (rambling with large words)

Re: select! not present but reject! is
 

Hi --

On Fri, 7 Oct 2005, Rob Rypka wrote:

> 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

--
David A. Black
dblack@wobblini.net

Re: select! not present but reject! is
 

On 10/6/05, David A. Black <dblack@wobblini.net> wrote:
> ...
>
> 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

Re: select! not present but reject! is
 

Hi --

On Fri, 7 Oct 2005, Jacob Fugal wrote:

> On 10/6/05, David A. Black <dblack@wobblini.net> wrote:
>> ...
>>
>> 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?

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

--
David A. Black
dblack@wobblini.net