[ruby-talk:13152] Re: gsub! & other in-place functions

I'm not sure I follow the logic that you need to know that something changed
when performing an operation. I think what you want is two things:

1. A method that might change the internal state of an object.
2. A method that reports on the internal state of the an object.

But to say you want both 1 and 2 is an operation that is not conceptually
crisp, or simple:

Perform operation and sometimes return something if the state of the object
changed, or nothing if the state is unchanged.

If I call some method, in any language, like unique, sort, reverse, I want
the operation performed. Whether it needed to be performed, or actually
changed anything is a different question, and therefore a different method.
If I want to know that something is already unique, already sorted, or that
the reverse ordering is the same as original, I would call methods like
isSorted, isUnique (or isSet), etc.

I personally found it confusing because the result of bang operations are
not consistent. And frankly, if bang operations are dangerous, having them
sometimes return nil, sometimes not, makes them even more dangerous!
Likewise, not consistently including the bang symbol is just as confusing.

I can understand and support the need to maintain methods for the sake of an
existing code base. But you shouldn't say that there are good design reasons
for inconsistent behaviour and labeling. The bang methods violate the
principle of least surprise (as described by Dave and Andy). Is there ever a
good reason to do this? I think there are excuses, but no reasons. I'd
rather hear the admission that yes, Ruby isn't perfect, it does have
inconsistencies, and these are some of them.

After all, Ruby _is_ a great language.

Being honest that it has some flaws is more useful than pretending that
every design choice that was made still makes complete sense just because
it's too hard to go back and change. The fact that it might be too hard to
go back change is all the reason you need. The other arguments, however,
seem weak, if not completely spurious.

Brian.