From: "David A. Black" <dblack@...>
Date: 2005-08-04T22:42:58+09:00
Subject: Re: a restricted send (was: Re: ruby-dev summary 26468-26661)

Hi --

On Thu, 4 Aug 2005, Martin Elzen wrote:

> Dan wrote:
>> > [ruby-dev:26616] public method
>> >   Seki asked about features like 'public', 'private' and 'protected', 
>> since He tried to change his
>> >   codes in dRuby to check restriction of method calls. In this issue, he 
>> proposed a new method like
>> >   'send', which can't call private methods. Matz will accept his idea if 
>> its appropriate name is decided.
>>> 
>> 
>> deliver
>> direct
>> dispatch
>> issue
>> post
>> connect
>> transmit
>> call
>> 
>> Of these, I like "call" the most, but I'm aware of the confusion it
>> might cause wrt Method#call.
>
> Please, no!  A lot of those alternatives are just synonyms for 'send', IMO, 
> and I think it would just add one more unnecessary little detail all Ruby 
> programmers will need to remember (as in: the difference between 'send' and 
> 'post', or whatever).  If this route *needs* to be taken, I'd much prefer 
> either:
> - giving send a kind of destination-method-type enum, which defaults to ORing 
> private, protected, and public together
> (so that calling send as you would today keeps working as it does now, by 
> default, but that you can, if you want, specify that it will only call 
> private, or protected, or private and protected methods...)
> - defining additional send_private and send_protected functions that work 
> just like send but only 'send-to' private or protected methods...

Another possibility would be perhaps a "secret" (or something) level
of protection:

   def x
   end

   secret :x

which would mean not even to be acknowledged as existing when
requested from outside by "send".


David

-- 
David A. Black
dblack@wobblini.net