A restricted send (was: Re: ruby-dev summary 26468-26661)

ruby-talk
1

Hi --

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

···

On Thu, 4 Aug 2005, Martin Elzen wrote:

--
David A. Black
dblack@wobblini.net

2

"David A. Black" <dblack@wobblini.net> writes:

Hi --

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

It's likely you forget a method then, though.

IMO, all methods to be called on possibly "dangerous" ways should be
explictly declared. It's just too easy to create security holes.

···

David A. Black

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org