From: Joel VanderWerf <vjoel@...>
Date: 2005-08-30T06:50:15+09:00
Subject: Re: Method behaves differently when called using #send

David A. Black wrote:
> Hi --
> 
> On Tue, 30 Aug 2005, Ara.T.Howard wrote:
> 
>> On Tue, 30 Aug 2005, David A. Black wrote:
>>
>>> Hi --
>>>
>>> On Tue, 30 Aug 2005, Daryl Richter wrote:
>>>
>>>>
>>>> I'm a Smalltalker, so I agree that characterizing this as
>>>> "dangerous" is overstated.  I think "advanced feature" is perhaps
>>>> more accurate?
>>>
>>>
>>> I'm a Rubyist, and I think it's a close call :-)  Admittedly, part of my
>>> clinging to send! is my desire not to see a completely different
>>> method name
>>> for the non-private version.  But I haven't come up with anything very
>>> inspired by way of an alternative to fcall.
>>
>>
>>  dispatch(a_message, *args, &block)
>>
>>  post(a_message, *args, &block)
> 
> 
> My problem with this kind of name is that it isn't clear which one
> would include private methods and which one wouldn't.  It would be
> arbitrary, and one would just have to memorize it (and, in explaining
> it, would probably have to account for it as being "for historical
> reasons" or some such).
> 
> 
> David
> 

That's part of the reason for #respond (which I proposed along with
#handle or #receive in ruby-talk/150606) as the new name of #send. It
can access a method only if the method is public, which is consistent
with how #respond_to? currently behaves: it returns false for
private/protected methods.

Also, I proposed these 3 receiver-oriented names because there is a
little cognitive dissonance in using

  x.send :foo

while at the same time thinking of the current self as the sender of
:foo to x. We don't think of x as sending anything (who would it be
sending to, itself?).

-- 
      vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407