From: dblack@...
Date: 2007-01-22T10:19:07+09:00
Subject: Re: Minor Change Proposal for Classes 'Object' and 'Method'

Hi --

On Mon, 22 Jan 2007, Yukihiro Matsumoto wrote:

> Hi,
>
> In message "Re: Minor Change Proposal for Classes 'Object' and 'Method'"
>    on Mon, 22 Jan 2007 09:27:28 +0900, dblack@wobblini.net writes:
>
> |> "a.method(:x)" looks up a method corresponding message :x, so that we
> |> can invoke the method later.  It is more accurate to call it "target"
> |> or "bound_method", as you pointed.  But I feel like there's a
> |> convention to call the target (or self) of a method as a "receiver" in
> |> OOP context.  Given that context, it's natural to call "a" receiver.
> |
> |I disagree; I don't think it's natural in context, because "receiver"
> |is a dynamic role and the result of a.method(:x) is reflective.
>
> I am not sure the difference between dynamic and reflective.

What I mean is: the object becomes a receiver because it actually
receives a message.  a.method(:x) tells us that a has an "x" method,
but it does not actually involve a set of events where a plays the
role "receiver".

> |method(:x) is more like a variation on respond_to?(:x).  Neither of
> |them actually puts the object in the receiver role; they just examine
> |the current type of the object.
>
> It is a receiver of message that retrieves a method corresponding a
> certain message name.  The object is a receiver when the method was
> invoked by ordinary message sending.

Yes... but this is a different scenario.  I think it's important for
the terminology to reflect that.  It's true that if obj.method(:x)
exists, then obj responds to "x" and can receive "x".  But it's still
separate things.

> |With Method#receiver, We'd end up saying things like, "obj is the
> |receiver of this method", which sounds like a mistake ("method" for
> |"message"), and also sounds like obj has actually played the receiver
> |role.
>
> Ah, I already say so often.  The "receiver" is most quick term for
> me to describe "self" in a method.

But when you do: a.method(:x), there's no self in a#x because a#x has
not been called.

>  m = a.method(:x)
>  m.call(args)

(Is that thread-safe? :-)

> represents
>
>  a.x(args)
>
> given that we can invoke the particular method, message "x" passing is
> done somewhere in above sequence, and "a" is a receiver of the passing.

But what does:

   m = a.method(:x)

represent -- *without* making the call to the method?  At that point,
there has been no event (direct or indirect) where a has received "x".
All we've done is create a Method object, based on a's interface.  The
only message-receiving is a receiving "method", but not "x".


David

-- 
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
    (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)