From: Trans <transfire@...>
Date: 2005-03-23T16:14:49+09:00
Subject: Re: RCR 296: Destructive methods return self

> 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:

I do not think there's much hope for multiple return values of this
sort --not unless Ruby were to change significantly. A differntiation
would have to be made between the returning of an array vs. the
returning of multiple values. Now I like the idea of returning multiple
values. I always wanted a way to feed return values into another method
as arguments _directly_ (without special * notation). But I suspect
multiple return values will simply cause too many undesired backward
compatability issues.

But what is worse about multiple return values is also what can be
frustrating about parameters: recalling the order of information. At
some point I can't help but feel like things would be a whole lot
easier if it were only a hash that could go into a method and only hash
that could come out.

On another note, something else to consider is that object's have the
ability to be "singlized", and this gives us the flexibility to flag
them as modified or not. So instead of returning nil when a destructive
method has no effect, just return self but flag the object as such.

  a = "123"
  if a.strip!.unmodified?

Then perhaps its time to just go all the way and support an in place
construction (umm... destruction ;-) on any method. Put the bang where
the dot is.

  if a!strip.unmodified?

T.