Re: method names in 1.9

On Nov 12, 2007 10:31 PM, David A. Black <[e-mail]> wrote:
> 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
>

Absolutelly agree. What I want to know if it everyone agrees.
Specially those in charge of deciding about the final release.
So, that would be everything with no "func_call" or other extrange things?


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

Of course.

>
> 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 fully understand Matz there, breaking send all the sudden is not
very good practice. We can make a transition.  sent! response! (or
whatever other name) and send in this release with a warning that send
will be obsoleted in the next one.


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

Object.method () have different behaviour than send. It doesn't use
method_missing. when it makes a lot of sense to use it. That behavior
should be deprecated.
object_a.send ("method_a")
object_a.method(:method_a).call
should be equivalents