select! not present but reject! is

[David A. Black]

Hi --

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

I hadn't thought we were talking about them. They seem OK to me,
though I could imagine reject actually being an in-place operation
even without the !.

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

See below about !, but also: I question what "select a subarray from
an array, in place" means. It sounds to me like the selected subarray
is *removed* from the array. Replacing the array with the selected
subarray seems to me to be a second transaction, not a select
operation per se.

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).
"Select these elements, but alter your contents and return yourself,
instead of someone new."

The ! doesn't mean that a method modifies the receiver in place,
though, but rather that this is a "dangerous" version of the method
and should be used carefully. The "danger" often has to do with
in-place change, but ! itself doesn't mean that.


David

 

[Jacob Fugal]

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 =3D=3D 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!.

We can agree on this, I suppose. Though I, personally, would like
select! to be the opposite of reject!, I don't need it -- as long as
there is *something* that's the opposite of reject!. Maybe keep!,
retain!, keep_only!, restrict! (or winnow!).

Most of my resistance was to the idea of having select!, but with a
function that wasn't converse to reject!. Reading more carefully
through past posts, I see now that you didn't mean select! should
exist with the alternate meaning, but that the possible alternate
meaning makes select! a bad naming choice. I don't quite agree on
that, but in the name of civility, we can just drop select! from the
discussion altogether and begin thinking of other names for the
converse of reject!. Sound good?

Jacob Fugal

 

[Rob Rypka]

You had to reply, didn't you...

I hadn't thought we were talking about them. They seem OK to me,
though I could imagine reject actually being an in-place operation
even without the !.

I had tried (and failed) to make this point earlier.

The ! doesn't mean that a method modifies the receiver in place,
though, but rather that this is a "dangerous" version of the method
and should be used carefully. The "danger" often has to do with
in-place change, but ! itself doesn't mean that.

I stand (somewhat) corrected. I had assumed some things based on
Pickaxe and my own delusional perspective into this world.

Before now, I had never been able to find information on the bang,
because I hadn't yet reduced my search results to replies from Matz.=20
Here's the relevant quote from [ruby-talk:02331]:

"Unlike Scheme, not all change-in-place functions are named with
exclamation mark. In Ruby, exclamation mark means `MORE dangerous',
or `may cause surprise' than non-bang counterpart, i.g. in-place
modification by `gsub!' may let you surprise, comparing copying
`gsub'."

I'm not trying to be mean by nit-picking a non-native speaker's
English, I'd like some clarification. I knew that methods existed
that modified the object without !, but their names were pretty clear
(e.g., delete_if). I thought the ! was there to imply modification of
the receiver, which could lead to unexpected results if used on a
function argument.

Are there any ! methods that don't modify the receiver? Are there any
! methods that do not have normal "non-dangerous" counterparts?

I can't think of anything that would not modify the object, but be
considered "dangerous," unless it's going to cause your sysadmin to
come to your office and beat you with a shovel.

Then again, the proposed select! seems to have caused you surprise, so
I think the name still fits

I think select! is the right name for a proposed companion to reject!,
but others don't, so I'm open. It's funny how I seem to argue most
about things that don't really matter to me (like the name of this
method).

 

[Bill Kelly]

Are there any ! methods that don't modify the receiver?

exit!


(Kind of an edge case, eh ;-)


Regards,

Bill

 

[Gavin Sinclair]

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

Perhaps not, but in this case, inconsistency would be unforgivable.
You should be able to predict how a method will work based on your
knowledge of how other, similar methods work.

In this case it's absolutely clear.

arr = (1..10).to_a
arr.map! { |n| n*n } # -> arr == [1,4,9,...,100]; self is returned

arr = (1..10).to_a
arr.reject! { |n| n % 3 == 0 } # -> arr == [1,2,4,5,7,8]; self is
returned

arr = (1..10).to_a
arr.select! { |n| n % 2 == 0 } # -> arr == [1,3,5,7,9]; self is
returned

It's a no-brainer. Consistency is paramount!

Cheers,
Gavin

 

[David A. Black]

Hi --

Perhaps not, but in this case, inconsistency would be unforgivable.

As I've said repeatedly, I am *not* suggesting that Ruby adopt a
select! method that does something other than the opposite of reject!.
I am suggesting that Ruby *not* adopt a select! method at all, because
select! is (in my view) a bad name for a method that does the opposite
of reject!, and having it do anything else would be confusing.

You should be able to predict how a method will work based on your
knowledge of how other, similar methods work.

In this case it's absolutely clear.

See earlier in thread -- there's been a lot of discussion and
disagreement.

arr = (1..10).to_a
arr.select! { |n| n % 2 == 0 } # -> arr == [1,3,5,7,9]; self is
returned

It's a no-brainer. Consistency is paramount!

Your select! works exactly like reject!. That might be a bit too much
consistency


David

 

[Gavin Sinclair]

arr = (1..10).to_a
arr.select! { |n| n % 2 == 0 } # -> arr == [1,3,5,7,9]; self is
returned

It's a no-brainer. Consistency is paramount!

Your select! works exactly like reject!. That might be a bit too much
consistency

Ah, you can never have too much consistency...

Gavin

 

[Devin Mullins]

The ! doesn't mean that a method modifies the receiver in place,
though, but rather that this is a "dangerous" version of the method
and should be used carefully. The "danger" often has to do with
in-place change, but ! itself doesn't mean that.

True, but the large majority of ! methods are simply in-place
equivalents of their non-bang friends:

---Instance
methods------------------------------------------------------------
Hash#merge!
hsh.merge!(other_hash) => hsh
hsh.update(other_hash) => hsh
hsh.merge!(other_hash){|key, oldval, newval| block} => hsh
hsh.update(other_hash){|key, oldval, newval| block} => hsh
------------------------------------------------------------------------
Adds the contents of _other_hash_ to _hsh_, overwriting entries
with duplicate keys with those from _other_hash_.

h1 = { "a" => 100, "b" => 200 }
h2 = { "b" => 254, "c" => 300 }
h1.merge!(h2) #=> {"a"=>100, "b"=>254, "c"=>300}

----------------------------------------------------------- Hash#reject!
hsh.reject! {| key, value | block } -> hsh or nil
------------------------------------------------------------------------
Equivalent to +Hash#delete_if+, but returns +nil+ if no changes
were made.

------------------------------------------------------------ Array#uniq!
array.uniq! -> array or nil
------------------------------------------------------------------------
Removes duplicate elements from _self_. Returns +nil+ if no changes
are made (that is, no duplicates are found).

a = [ "a", "a", "b", "b", "c" ]
a.uniq! #=> ["a", "b", "c"]
b = [ "a", "b", "c" ]
b.uniq! #=> nil

----------------------------------------------------------- Array#slice!
array.slice!(index) -> obj or nil
array.slice!(start, length) -> sub_array or nil
array.slice!(range) -> sub_array or nil
------------------------------------------------------------------------
Deletes the element(s) given by an index (optionally with a length)
or by a range. Returns the deleted object, subarray, or +nil+ if
the index is out of range. Equivalent to:

def slice!(*args)
result = self[*args]
self[*args] = nil
result
end

a = [ "a", "b", "c" ]
a.slice!(1) #=> "b"
a #=> ["a", "c"]
a.slice!(-1) #=> "c"
a #=> ["a"]
a.slice!(100) #=> nil
a #=> ["a"]

------------------------------------------------------------ Array#sort!
array.sort! -> array
array.sort! {| a,b | block } -> array
------------------------------------------------------------------------
Sorts _self_. Comparisons for the sort will be done using the +<=>+
operator or using an optional code block. The block implements a
comparison between _a_ and _b_, returning -1, 0, or +1. See also
+Enumerable#sort_by+.

a = [ "d", "a", "e", "c", "b" ]
a.sort #=> ["a", "b", "c", "d", "e"]
a.sort {|x,y| y <=> x } #=> ["e", "d", "c", "b", "a"]

--------------------------------------------------------- Array#collect!
array.collect! {|item| block } -> array
array.map! {|item| block } -> array
------------------------------------------------------------------------
Invokes the block once for each element of _self_, replacing the
element with the value returned by _block_. See also
+Enumerable#collect+.

a = [ "a", "b", "c", "d" ]
a.collect! {|x| x + "!" }
a #=> [ "a!", "b!", "c!", "d!" ]

--------------------------------------------------------- Array#compact!
array.compact! -> array or nil
------------------------------------------------------------------------
Removes +nil+ elements from array. Returns +nil+ if no changes were
made.

[ "a", nil, "b", nil, "c" ].compact! #=> [ "a", "b", "c" ]
[ "a", "b", "c" ].compact! #=> nil

---------------------------------------------------------- Array#reject!
array.reject! {|item| block } -> array or nil
------------------------------------------------------------------------
Equivalent to +Array#delete_if+, deleting elements from _self_ for
which the block evaluates to true, but returns +nil+ if no changes
were made. Also see +Enumerable#reject+.

--------------------------------------------------------- Array#reverse!
array.reverse! -> array
------------------------------------------------------------------------
Reverses _self_ in place.

a = [ "a", "b", "c" ]
a.reverse! #=> ["c", "b", "a"]
a #=> ["c", "b", "a"]

------------------------------------------------------------- Array#map!
array.collect! {|item| block } -> array
array.map! {|item| block } -> array
------------------------------------------------------------------------
Invokes the block once for each element of _self_, replacing the
element with the value returned by _block_. See also
+Enumerable#collect+.

a = [ "a", "b", "c", "d" ]
a.collect! {|x| x + "!" }
a #=> [ "a!", "b!", "c!", "d!" ]

--------------------------------------------------------- Array#flatten!
array.flatten! -> array or nil
------------------------------------------------------------------------
Flattens _self_ in place. Returns +nil+ if no modifications were
made (i.e., _array_ contains no subarrays.)

a = [ 1, 2, [3, [4, 5] ] ]
a.flatten! #=> [1, 2, 3, 4, 5]
a.flatten! #=> nil
a #=> [1, 2, 3, 4, 5]

----------------------------------------------------------- String#gsub!
str.gsub!(pattern, replacement) => str or nil
str.gsub!(pattern) {|match| block } => str or nil
------------------------------------------------------------------------
Performs the substitutions of +String#gsub+ in place, returning
_str_, or +nil+ if no substitutions were performed.

----------------------------------------------------------- String#succ!
str.succ! => str
str.next! => str
------------------------------------------------------------------------
Equivalent to +String#succ+, but modifies the receiver in place.

------------------------------------------------------- String#downcase!
str.downcase! => str or nil
------------------------------------------------------------------------
Downcases the contents of _str_, returning +nil+ if no changes were
made.

-------------------------------------------------------- String#squeeze!
str.squeeze!([other_str]*) => str or nil
------------------------------------------------------------------------
Squeezes _str_ in place, returning either _str_, or +nil+ if no
changes were made.

--------------------------------------------------------- String#rstrip!
str.rstrip! => self or nil
------------------------------------------------------------------------
Removes trailing whitespace from _str_, returning +nil+ if no
change was made. See also +String#lstrip!+ and +String#strip!+.

" hello ".rstrip #=> " hello"
"hello".rstrip! #=> nil

---------------------------------------------------------- String#slice!
str.slice!(fixnum) => fixnum or nil
str.slice!(fixnum, fixnum) => new_str or nil
str.slice!(range) => new_str or nil
str.slice!(regexp) => new_str or nil
str.slice!(other_str) => new_str or nil
------------------------------------------------------------------------
Deletes the specified portion from _str_, and returns the portion
deleted. The forms that take a +Fixnum+ will raise an +IndexError+
if the value is out of range; the +Range+ form will raise a
+RangeError+, and the +Regexp+ and +String+ forms will silently
ignore the assignment.

string = "this is a string"
string.slice!(2) #=> 105
string.slice!(3..6) #=> " is "
string.slice!(/s.*t/) #=> "sa st"
string.slice!("r") #=> "r"
string #=> "thing"

----------------------------------------------------------- String#chop!
str.chop! => str or nil
------------------------------------------------------------------------
Processes _str_ as for +String#chop+, returning _str_, or +nil+ if
_str_ is the empty string. See also +String#chomp!+.

----------------------------------------------------- String#capitalize!
str.capitalize! => str or nil
------------------------------------------------------------------------
Modifies _str_ by converting the first character to uppercase and
the remainder to lowercase. Returns +nil+ if no changes are made.

a = "hello"
a.capitalize! #=> "Hello"
a #=> "Hello"
a.capitalize! #=> nil

------------------------------------------------------------- String#tr!
str.tr!(from_str, to_str) => str or nil
------------------------------------------------------------------------
Translates _str_ in place, using the same rules as +String#tr+.
Returns _str_, or +nil+ if no changes were made.

----------------------------------------------------------- String#next!
str.succ! => str
str.next! => str
------------------------------------------------------------------------
Equivalent to +String#succ+, but modifies the receiver in place.

---------------------------------------------------------- String#chomp!
str.chomp!(separator=$/) => str or nil
------------------------------------------------------------------------
Modifies _str_ in place as described for +String#chomp+, returning
_str_, or +nil+ if no modifications were made.

------------------------------------------------------- String#swapcase!
str.swapcase! => str or nil
------------------------------------------------------------------------
Equivalent to +String#swapcase+, but modifies the receiver in
place, returning _str_, or +nil+ if no changes were made.

-------------------------------------------------------- String#reverse!
str.reverse! => str
------------------------------------------------------------------------
Reverses _str_ in place.

----------------------------------------------------------- String#tr_s!
str.tr_s!(from_str, to_str) => str or nil
------------------------------------------------------------------------
Performs +String#tr_s+ processing on _str_ in place, returning
_str_, or +nil+ if no changes were made.

---------------------------------------------------------- String#strip!
str.strip! => str or nil
------------------------------------------------------------------------
Removes leading and trailing whitespace from _str_. Returns +nil+
if _str_ was not altered.

------------------------------------------------------------ String#sub!
str.sub!(pattern, replacement) => str or nil
str.sub!(pattern) {|match| block } => str or nil
------------------------------------------------------------------------
Performs the substitutions of +String#sub+ in place, returning
_str_, or +nil+ if no substitutions were performed.

--------------------------------------------------------- String#upcase!
str.upcase! => str or nil
------------------------------------------------------------------------
Upcases the contents of _str_, returning +nil+ if no changes were
made.

--------------------------------------------------------- String#delete!
str.delete!([other_str]+>) => str or nil
------------------------------------------------------------------------
Performs a +delete+ operation in place, returning _str_, or +nil+
if _str_ was not modified.

--------------------------------------------------------- String#lstrip!
str.lstrip! => self or nil
------------------------------------------------------------------------
Removes leading whitespace from _str_, returning +nil+ if no change
was made. See also +String#rstrip!+ and +String#strip!+.

" hello ".lstrip #=> "hello "
"hello".lstrip! #=> nil

---Singleton
methods---------------------------------------------------------
Process::exit!
Process.exit!(fixnum=-1)
------------------------------------------------------------------------
Exits the process immediately. No exit handlers are run. _fixnum_
is returned to the underlying system as the exit status.

Process.exit!(0)

Nonetheless, I don't care about select!. Someone made a comment, err,
somewhere, about how all the stupid shit gets bantered to death simply
because more people understand it. It might have been Jason Hunter (of
JDOM fame). Not sure. It was funny, though.

Devin
And yes, it's merely a coincidence that the exception to the rule is the
last one in this list...

 

[Devin Mullins]

True, but the large majority of ! methods are simply in-place
equivalents of their non-bang friends:

Wow. I just executed circular logic perfectly! Good night, all.

Devin
(Also, apologies to those who didn't want to see a curse word in my last
email. Really, judgment impaired. Good night.

 

[David A. Black]

Hi --

True, but the large majority of ! methods are simply in-place equivalents of
their non-bang friends:

[hundreds of lines of ri output snipped :-]

Heavens -- I think we all knew that already There's one that I
don't think you included: Tempfile#close! which closes and unlinks the
file.

One reason I think it's useful to remember the real meaning of ! is
that gives one a potentially useful tool to use in one's own classes.
I don't know how many people actually write bang methods. I've done
it once or twice.


David

 

[Martin DeMello]

Nonetheless, I don't care about select!. Someone made a comment, err,
somewhere, about how all the stupid shit gets bantered to death simply
because more people understand it. It might have been Jason Hunter (of
JDOM fame). Not sure. It was funny, though.

You're probably thinking about this:

http://www.unixguide.net/freebsd/faq/16.19.shtml

martin

 

[Ara.T.Howard]

Hi --

True, but the large majority of ! methods are simply in-place equivalents
of their non-bang friends:

[hundreds of lines of ri output snipped :-]

Heavens -- I think we all knew that already There's one that I don't
think you included: Tempfile#close! which closes and unlinks the file.

One reason I think it's useful to remember the real meaning of ! is that
gives one a potentially useful tool to use in one's own classes. I don't
know how many people actually write bang methods. I've done it once or
twice.

an interesting question, i seem to do it alot:

jib:~/eg/ruby > find -name '*rb'|xargs -n1 egrep '^\s*def [^;(]+\!'|sort -u
def add!
def chop!
def close!
def close!
def collect!
def Complex.new!(a, b=0)
def ConfigTable.get_entry!(name)
def delete!(del)
def diagonal!(val=1)
def error! #:nodoc:
def escape! char, esc = 0x5c.chr
def escape! s, char, esc
def escape! s, char, esc
def escape! s, char, esc
def expand! string, opts = {}
def expand! string, variables = {}
def flatten!
def free!
def give_up!
def give_up! label = 'attempt'
def indent!
def maim!(pid, *sigs)
def map!
def map!
def mask!(mask)
def merge!(oth)
def next! implementation_changed = true, interface_changed = false, backwards_compatible = false
def normalize!
def order!(argv = ARGV, &nonopt)
def order!(&blk) options.order!(self, &blk) end
def parse!(argv = ARGV)
def parse!() options.parse!(self) end
def permute!(argv = ARGV)
def permute!() options.permute!(self) end
def Rational.new!(num, den = 1)
def reject!
def reject! &block
def reject! &block
def replace!(oth)
def select!( ypath_str )
def slice!(*args)
def squeeze!(del=nil)
def succ!
def test_collect!
def test_reject!
def tr!(from, to)
def tr_s!(from, to)
def try_again!
def try_again! label = 'attempt'
def update!
def update!
def update!

although about 10% of those aren't mine and i seem to stick to a few common
names (update!) in that list. still there are around 20 legit ones.

cheers.

-a
--
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| Your life dwells amoung the causes of death
| Like a lamp standing in a strong breeze. --Nagarjuna
===============================================================================

 

[David A. Black]

Hi --

You're probably thinking about this:

http://www.unixguide.net/freebsd/faq/16.19.shtml

(I'd want to give Professor Parkinson the benefit of the doubt and
assume that his book actually isn't as trite as that paraphrase
suggests. But I don't know. The "Someone's Law" formula certainly
operates often as a magic ticket to longevity

Anyway.... at the risk of getting meta-meta-meta, I'd like to suggest
that discussing details of things like method names (in this case,
including Matz indicating that he was interested in what people think)
is actually not "stupid". We're just lucky that Matz pays attention
to details like this, over and over again year after year. It's that,
and not a deterministic, mechanistic "Well, X does this, so Y has to
do it" logic, that makes Ruby so beautiful.


David

 

[Devin Mullins]

Heavens -- I think we all knew that already There's one that I
don't think you included: Tempfile#close! which closes and unlinks the
file.

Yeah, I just used ObjectSpace, so it didn't pick up any stdlib stuff.
That was pretty stupid of me, but like I said, it was late, and I needed
sleep.

One reason I think it's useful to remember the real meaning of ! is
that gives one a potentially useful tool to use in one's own classes.
I don't know how many people actually write bang methods. I've done
it once or twice.

Point. I have never written a bang method. May I hang my head in shame.

Anyway.... at the risk of getting meta-meta-meta, I'd like to suggest
that discussing details of things like method names (in this case,
including Matz indicating that he was interested in what people think)
is actually not "stupid". We're just lucky that Matz pays attention
to details like this, over and over again year after year. It's that,
and not a deterministic, mechanistic "Well, X does this, so Y has to
do it" logic, that makes Ruby so beautiful.

1. Agreed; attention to detail is what helped make Ruby so *tear* beautiful.
2. "Well, X does this, so Y has to do it" is just another aesthetic. In
this case, I think it applies to me, but to each his own.
3. Indeed, you're right. It's more important to have a small set of
cohesive and perfect doohickeys than a large set of jumbled and POS
ones. So, fine, let us continue the select! discussion....

I say we name it select! and alias as keep! -- that way, somebody ri'ing
it will be able to infer its meaning the English way, and somebody not
ri'ing will be able to infer its meaning from the parallels already
drawn in 90+% of the core bang methods (where x.foo! _=_ x = x.foo...
sort of).

Devin

 

[David A. Black]

Hi --

3. Indeed, you're right. It's more important to have a small set of cohesive
and perfect doohickeys than a large set of jumbled and POS ones. So, fine,
let us continue the select! discussion....

What's POS?

I say we name it select! and alias as keep! -- that way, somebody ri'ing it
will be able to infer its meaning the English way, and somebody not ri'ing
will be able to infer its meaning from the parallels already drawn in 90+% of
the core bang methods (where x.foo! _=_ x = x.foo... sort of).

(But how many times is foo! not, on its own, a good method name for
what it does? I still prefer that there not be a method called
select!, but I dare say that's pretty evident by now

keep! implies keep. I think keep (without the !) would be an inplace
operation already. Or maybe keep_all { <test> }.


David

 

[Devin Mullins]

Hi --



What's POS?

Piece of... err... sunshine...

keep! implies keep. I think keep (without the !) would be an inplace
operation already. Or maybe keep_all { <test> }.

Yeah, I like keep_all. I have the strongest feeling we're developing a
camel, though...

Devin
(a camel is a horse designed by committee...)

 

[Ryan Leavengood]

keep! implies keep. I think keep (without the !) would be an inplace
operation already. Or maybe keep_all { <test> }.

I vote we add keep_all or keep_if, and make select! a synonym for it.
Just like delete_if and reject!.

I feel symmetry and consistency is better than sticking to ideals of
the English language. Of course I think select! makes as much sense as
reject!, so for me it is a moot point.

Ryan

 

[David A. Black]

Hi --

I vote we add keep_all or keep_if, and make select! a synonym for it.
Just like delete_if and reject!.

delete_if and reject! aren't quite synonyms, though:

irb(main):010:0> [1,2,3,4].delete_if {|x| x > 4 }
=> [1, 2, 3, 4]
irb(main):011:0> [1,2,3,4].reject! {|x| x > 4 }
=> nil

I definitely like keep_if better than select! for conditional keeping,
but because of the delete_if/reject! difference, one would expect
keep_if (or delete_unless, maybe?) to behave like delete_if rather
than like reject!. (I know this isn't a problem if select! exists
too, but I'm still not in favor of that name for this functionality.)

I feel symmetry and consistency is better than sticking to ideals of
the English language. Of course I think select! makes as much sense as
reject!, so for me it is a moot point.

"Ruby: the triumph of balance over symmetry" (my personal Ruby slogan
Not that I'm anti-symmetry -- I just like that it isn't always a
determinant.


David

 

[Hal Fulton]

I vote we add keep_all or keep_if, and make select! a synonym for it.
Just like delete_if and reject!.

I feel symmetry and consistency is better than sticking to ideals of
the English language. Of course I think select! makes as much sense as
reject!, so for me it is a moot point.

It's not a matter of the English language as such -- English is just
the language that the keywords and method names are based on.

I oppose select! not on the basis on English purity, but on that of
Ruby purity.

One of the reasons I like Ruby is that Matz has *not* chosen to
slavishly follow symmetry and consistency.

Just my opinion.


Hal

 

[Gavin Sinclair]

It's not a matter of the English language as such -- English is just
the language that the keywords and method names are based on.

I oppose select! not on the basis on English purity, but on that of
Ruby purity.

Can you justify that opposition in the context of the following Array
methods?

collect! compact! flatten! map! reject! reverse!
slice! sort! uniq!

I've read the whole thread (perhaps too quickly), and don't see what at
all is controversial about #select! as an in-place #select.

I'm neither advocating it nor opposing it on its merits, but I think
it's equally meritorious as all of the above. Or even more:
#map!/#collect! and #uniq! are quite unappealing to me.

Point is: I doubt anyone on this thread would complain (even privately)
about #select! if it had been there all along. That's not to belittle
the discussion now, but it's a useful perspective.

And amongst all the praising of Ruby's balance over symmetry etc., I
can't help thinking that if the core classes were redesigned from
scratch, they'd be a little cleaner than they are now. [1] That is
inevitable and not a criticism. Such a criticism would be niggardly in
respect of the overall beauty of the language.

Finally, FWIW, here's a list of Array methods that _don't_ have an
in-place counterpart (including Enumerable methods):

find_all grep sort_by

Gee, not many! (Especially as #find_all is just #select.) As a lover
of minutae, I'd like to hear people's arguments for and against banging
these (ooh errrr)

Cheers,
Gavin

P.S. That faint buzz in the back of my mind has become clearer:
extensions.rubyforge.org defines Array#select! I put it there at
someone's request ages ago.