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