In data 3/22/2005, "Hal Fulton" <hal9000 / hypermetrics.com> ha scritto:

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

+1 for interrobang!

>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

E