From: dblack@...
Date: 2007-01-22T09:27:28+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 02:03:35 +0900, dblack@wobblini.net writes:
>
> |That's all correct, but the word "receiver" doesn't communicate it to
> |me.  Given this:
> |
> |   m = a.method(:x)
> |
> |I do not consider it optimal to describe a as m's "receiver".  It's a
> |re-definition of the term, and I think it would lead to confusion.
>
> "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.
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.

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.

I don't know -- it just seems that with so many words available, it's
better not to re-use a word that's not a complete fit, even if it's
related to the same problem domain.


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)