From: Daniel Amelang <daniel.amelang@...>
Date: 2005-03-22T11:31:08+09:00
Subject: Re: RCR 296: Destructive methods return self

Yes, I am liking the proposal less and less as time goes on. And I'm
the one who wrote it!

I'm *am* liking the (1) remove bang methods altogether idea more and
more. It has the positive (minor) side effect of reducing the number
of instance methods for String and Array, which is nice. And of
course, it eliminates the chaining confusion, since bang methods are
no longer an option. Losing the bang methods has also proven to be
only a minor loss in the efficiency category (we could live without
them).

But, this alone doesn't solve the problem with the modification
detection. Is it _that_ common? I've heard only one person complain so
far. Yet, you (matz) seem to be concerned about losing that
functionality, so I'll be concerned too. :)

Will (2) really solve the problem, or just mitigate it slightly?

(3) is an interesting solution to the detection problem. Perhaps
having real multiple return values will solve some other issues in
Rubyland also (anyone?). Using a modified version of the 'strip'
method, let me illustrate a minor modification in the language that
allows for easier use of multiple return values:

class String
  # The new strip returns both the string result and
  # a flag that some change occured.
  def strip 
    ...
    return result, changed 
  end
end

# This works now:
str, changed = "hello ".strip

# But currently, when you only want the string result, you have to do this:
str, _ = "hello ".strip

# Because this:
str = "hello ".strip

# gives you an array :(

# Why not make the minor change such that this:
*str = "hello ".strip 

# gives you the array and this:

str = "hello ".strip

only gives you the _first_ of the multiple return values. That way we can return
multiple return values without requiring the receivers to use _ all the time
to throw away the rest.

I'm done. Thanks for taking the time to consider my proposal.

Dan