Yukihiro Matsumoto wrote:
>   (2) current bang methods are bad because they work most of the
>       cases, and fail if no change has made.  thus let us make bang
>       methods return something other than self, boolean for example,
>       to fail always.  this forces no chaining of bang methods.

I think this one is the most consistent way of doing things.  In a way, 
using chaining with receiver-modifying methods doesn't make sense.  You 
really don't want to modify the return value of the method, you want to 
modify the original object.  I think the main reaon people want to chain 
bang methods is that they don't like having to type the variable a lot 
of times.

the_config_string_for_foo = $stdin.gets
the_config_string_for_foo.strip!.downcase!

is easier to type than

the_config_string_for_foo = $stdin.gets
the_config_string_for_foo.strip!
the_config_string_for_foo.downcase!

But it seems to me that what people are really looking for is a way to 
apply multiple methods to an object without having to retype it's name:

the_config_string_for_foo = $stdin.gets
the_config_string_for_foo.apply { strip!; downcase! }

This has been proposed a few times, I think.  I can't remember how you 
(Matz) felt about it.  Is the reason Ruby doesn't have a way to do it 
because you don't like the idea, or you were hoping for consensus on the 
exact method of doing it?

>   (4) add some kind of reference counting, and if the receiver is
>       referenced from only one place, modify the receiver in place, to
>       gain performance.

This sounds like "more work for Matz", but also a really good solution. 
  Most of the time people only want bang methods for efficiency.  If 
that weren't an issue then it would be even easier to have the 
bang-methods return boolean (modified / not modified) and then people 
could choose the method based on what they were after (chaining vs. "was 
something changed") and not based on efficiency.

Ben