Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > select! not present but reject! is

Reply
Thread Tools

select! not present but reject! is

 
 
Geert Fannes
Guest
Posts: n/a
 
      10-05-2005
------_=_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--


 
Reply With Quote
 
 
 
 
Gene Tani
Guest
Posts: n/a
 
      10-05-2005
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.


 
Reply With Quote
 
 
 
 
Jacob Fugal
Guest
Posts: n/a
 
      10-05-2005
On 10/5/05, Gene Tani <(E-Mail Removed)> 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


 
Reply With Quote
 
David A. Black
Guest
Posts: n/a
 
      10-05-2005
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
http://www.velocityreviews.com/forums/(E-Mail Removed)


 
Reply With Quote
 
Jacob Fugal
Guest
Posts: n/a
 
      10-06-2005
On 10/5/05, David A. Black <(E-Mail Removed)> 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


 
Reply With Quote
 
Yukihiro Matsumoto
Guest
Posts: n/a
 
      10-06-2005
Hi,

In message "Re: select! not present but reject! is"
on Thu, 6 Oct 2005 06:47:35 +0900, "David A. Black" <(E-Mail Removed)> 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.


 
Reply With Quote
 
Rob Rypka
Guest
Posts: n/a
 
      10-06-2005
On 10/6/05, Yukihiro Matsumoto <(E-Mail Removed)> 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)


 
Reply With Quote
 
David A. Black
Guest
Posts: n/a
 
      10-06-2005
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
(E-Mail Removed)


 
Reply With Quote
 
Jacob Fugal
Guest
Posts: n/a
 
      10-07-2005
On 10/6/05, David A. Black <(E-Mail Removed)> 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


 
Reply With Quote
 
David A. Black
Guest
Posts: n/a
 
      10-07-2005
Hi --

On Fri, 7 Oct 2005, Jacob Fugal wrote:

> On 10/6/05, David A. Black <(E-Mail Removed)> 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
(E-Mail Removed)


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
hashing for absent but not present cases Marc Girod Perl Misc 7 10-15-2010 05:12 AM
CSS present in DOM but not applied Flintstone HTML 5 01-18-2008 07:26 PM
OS present but not present. XPD NZ Computing 4 04-11-2007 11:22 PM
Missing calendar in Windows-Mozilla (but present in Linux version)! Hallvard Tangeraas Firefox 7 09-29-2004 05:41 PM
Schema: express that "@a present if and only if @b present", where @a, @b are attributes Ralf Wahner XML 5 12-24-2003 11:37 AM



Advertisments