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 10:19:07 +0900, dblack / wobblini.net writes:
>
> |>  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".
>
> Ordinary message passing
>
>  a.x
>
> does the following steps
>
>  (1) retrieve a class of the object a.
>  (2) look-up method table in a class by name x
>  (3) if it doesn't exist, looks for super-class table
>  (4) invoke a method with self bound to the object a.
>
> whereas
>
>  a.method(:x)
>
> does steps 1 through 3, and creates a method object reserved for the
> 4th step.  When we can call the object a in the former sequence a
> receiver, what is wrong calling receiver too in the latter sequence,
> even though target or bound_object is more accurate.  Do you think
> possible confusing critical?

I think the possible confusion can be avoided, so I'd rather avoid it.
If you do this:

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

I can understand saying that a is the receiver of :x (even though it's
an "exploded" path to message-receiving).  But the terminology I don't
like is saying that a is the "receiver" of *m*:

   m.receiver    # a

I've always found it very helpful (for myself and others) to keep the
whole sequence very visible (message sending, method lookup, method
execution), and I think that using "receiver" as an attribute of a
method object does a short-circuit in the terminology that makes it
harder to explain and understand.


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)