On Nov 12, 8:31 am, "David A. Black" <dbl... / rubypal.com> wrote:
> Hi --
>
>
>
> On Mon, 12 Nov 2007, Jordi wrote:
> > On Nov 12, 2007 8:42 PM, David A. Black <dbl... / rubypal.com> 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 have of course argued for object_send/instance_send (vs your send/
send!) since it clearly delineates these methods for their meta-
nature, and especially 'instance_' which clearly indicates a by-pass
public interface, just like instance_variable_get/set. Aliasing #send
to #instance_send, *for the time being*, would give people time to
transition.

Short of that, I'm not sure it's really worth it.Yes, send/send! have
a nice symmetry, but #respond/#send are decent choices and save a lot
of trouble w/ backward compatibility. It's not like Ruby doesn't have
a few of variances like this already, #update for instance wasn't
deprecated when we gained #merge!.

But while we are discussing it, I'd like to remind everyone of Ara's
idea of a send operator. (The exact operator syntax is subjective of
course):

  obj~>'blah'
  obj~>['blah', arg1, agr2]

Sending a message without literal syntax is a very powerful
programming tool. I think a nice concise syntax like this can go a
long way.

(In addition Ara also suggested a meta-form of this operator that
bound the call directly to Object, to bypass any overrides, for use in
certain meta-programming purposes.)

T.