From: Jacob Fugal <lukfugl@...>
Date: 2005-10-07T09:46:23+09:00
Subject: 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 = []
  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