Re: method names in 1.9

On 12/11/2007, David A. Black <[e-mail]> wrote:
> Hi --
>
> On Mon, 12 Nov 2007, Jordi wrote:
>
> > Summing it up:
> >
> > - Surprising or not, sending messages is not the same that calling
> > methods in Ruby (there is  a real difference, see method_missing email
> > of Matthew in this thread).
> > - Honoring visibility is not the same that don't honoring it (obviously)
> >
> > So, we can have potentially 4 operations in Ruby 1.8.x:
> >
> > 1.- Call method honoring visibility
> > 2.- Call method not honoring visibility
> > 3.- Send message honoring visibility
> > 4.- Send message not honoring visibility
>
> I don't see how 1/2 differ from 3/4, except in the terminology. What
> we call "calling a method" on an object *is* sending a message.
> There's no choice on the programmer's part. The distinction is really
> from the object's perspective.
>
>

As far as I can understand it there are two features we might (not)
want when sending a message:
 - to honor visibility
 - to let the object handle the message with method_missing if there
is no matching method defined

0) Normally, the . operator uses both features. There might be uses
for other options as well.

In my view there is option needed
 1) for sending a message as if it was done with the . operator but
with dynamic method name without using eval (at least directly)
 2) for sending a message as above that is not handled by
method_missing. This defeats the use of proxy objects but will be
probably useful for implementation of the proxy objects.

I am less certain that sending a message without honoring visibility
is needed. If I want the method visible I should have made it visible
in the first place. On the other hand, when dealing with multiple
objects that are somehow tied together but should hide the internals
from the outside this would be probably useful. Then the other two
options come into play.
 3) send a message that does not honor visibility and uses method_missing
 4) send a message that does not honor visibility and does not use method_mising

As I understand it send currently does 3), and I would have to study
the documentation to figure out how to do the others. Even if there
are no premade methods for all the options it should be possible to
implement all with send and (1), and the method lists (ie check the
existence and visibility manually).

So basically what we are arguing about is naming of convenience
methods that do some checks for us. This is not very important in that
everybody can implement and name the methods anyway he wishes.

However, for these convenience methods to be convenient and useful at
all the names should be intuitive. Otherwise we can as well drop them
because next to nobody will use them, and any actual use would be only
confusing.

Thanks

Michal