Re: method names in 1.9

Hi --

On Mon, 12 Nov 2007, Jordi wrote:

> On Nov 12, 2007 8:42 PM, 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 mathew pointed out in his message, the difference appears when
> method_missing is called in an object that receives a send message
> with the name of a missing method. Calling the method directly fails.

I'd still argue that it goes like this:

   message gets sent to object (via '.' or send)
   object looks for corresponding method
     - if found, executes it
     - if not found, executes method_missing

At no point does the programmer directly call a method; it's always a
matter of sending a message, and having the object handle it. The only
direct calling of a method is:

   a_method_object.call

and even that is really a message-based operation.

> So, for the four options I wrote before, what are the options
> logical/desirable for Ruby?
> 
> Once you agree on that, how will that options called/implemented?

I believe that these two things should be exactly equivalent:

   obj.blah
   obj.send("blah")

The only reason send exists, I think, is to allow
dynamically-determined messages to be sent to objects. As for
visibility, I'm still in favor of (if it's necessary) send! for
invading private methods. Matz said in this thread that he thinks it
would break compatibility too much, but I think it's worth it.

> I think that solving those two points will solve the discussion
> clearly for everyone.
>
>
> I'd suggest stick to ONLY sending messages, options 3 and 4
> (object.method should be deprecated). Also I'd make a new more
> meaningful name for "send" and deprecate send for deletion in the next
> big release.

I think I'm getting confused. Do you mean the method #method should be
deprecated? Or that the dot for sending messages should be deprecated?
I don't think you actually mean either but I'm not following.


David

-- 
Upcoming training by David A. Black/Ruby Power and Light, LLC:
   * Advancing With Rails, Berlin, Germany, November 19-22
   * Intro to Rails, London, UK, December 3-6 (by Skills Matter)
See http://www.rubypal.com for details!