Hi --

On Mon, 29 Aug 2005, daz wrote:

>
> Yukihiro Matsumoto wrote:
>> David A. Black writes:
>>
>> |Here's another idea:
>> |
>> |Kernel#send
>> |Kernel#send!   # dangerous version, includes private methods
>>
>> It's bit different from my sense of dangerousness, but let me
>> consider.
>>
>> matz.
>>
>
> [replying to David]
>
> It's easy to understand the meaning of #send! when reading
> this thread because it is within context but, as Matz implies,
> bang! methods usually provide the destructive counterpart
> of a non-bang method (i.e. an object is modified in place
> rather than being copied first).
>     -- Yes, I know you know that :-)

Actually Matz has always said that while most ! methods perform
destructive operations, ! does not *mean* destructive.  It means
"more dangerous" than the corresponding non-bang method:

   As Hal pointed out, Scheme's bang is the mark for self-modifying
   functions, on the other hand, Ruby's bang is the mark for "more
   dangerous alternative; handle with care".

or, elsewhere:

   exit! does not modify anything.  Its ! means "more dangerous" than
   non bang version.

> There's nothing inherently dangerous about bang methods;
> we use them quite safely.

My use of "dangerous" rather than "destructive" came from Matz's
usage.  I suppose I should have said "more dangerous version", as Matz
does, rather than just "dangerous version" (though it's clear that I'm
lining up send and send! for direct comparison).

> Calling private methods could be dangerous but overloading
> the meaning of the "!" suffix needs careful consideration
> and I understand Matz' concern.

I don't think it's an overloading, just another (i.e., other than
receiver-changing) nuance of the "more dangerous" concept.  I actually
didn't understand Matz's concern fully.  I assume it's not
specifically about the fact that send! is not destructive, since
that's OK in a bang method.

> Having said that, my initial reaction to #send! was positive
> and, for insiders like yourself and for me too, it should be
> easy to remember -- for teaching and learning, though, it
> may create an obstacle.

I think that send/send! would be a lot easier to explain than
send/fcall, once the general meaning of ! is established.  But I can't
really predict.

> With 5 votes in support, I felt there was room for some balance.
> Any of the +1 voters strong enough to change their mind ?

I find that a rather uncollegial way to put it, but in my case, I
guess the answer is that I'm "weak" by your standards.  I believe
send/send! would be better than send and a completely differently
method name.


David

-- 
David A. Black
dblack / wobblini.net