From: Hal Fulton <hal9000@...>
Date: 2005-03-22T15:12:52+09:00
Subject: Re: RCR 296: Destructive methods return self

Obviously I'm only expressing my opinion here, which often
is nearly worthless:

Yukihiro Matsumoto wrote:
> Alternative plans:
> 
>   (1) remove bang methods altogether.

"The cradle is too short. Let's cut off the baby's feet."

>   (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.

Again, please no. I like chaining.

>   (3) introduce "real" multiple return values ala common lisp, and let
>       the first returned value as the receiver and the second return
>       value is boolean value to denote success/failure.

Interesting, but only if "the common case is the prettier one" and
back compatibility is maintained. I don't want to go sprinkling
commas and asterisks through old code.

>   (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.

Hmm, does this work? Would there be times it would not be obvious whether we
were changing the original object or not? If so, unacceptable.

I would almost suggest what I once suggested as a joke: Combine the ! and ?
suffixes.

    gsub!  returns self
    gsub!? returns self or nil  (yes, it looks silly)

Or alternatively:

    gsub!  returns self or nil as now
    gsub_! returns self (yes, it's ugly)

Or perhaps:

    Give the objects a "changed?" flag. Every bang method is expected to
    set it...

      obj.gsub!(...)  #  returns self and sets flag
      if obj.changed? then...   # not thread-friendly, but I could live with it

    Is that really an expensive solution?


Hal