Hi --

On Sun, 21 Jan 2007, gwtmp01 / mac.com wrote:

>
> On Jan 20, 2007, at 4:59 PM, dblack / wobblini.net wrote:
>> My problem with using "receiver" this way is that it's detached from
>> the process of receiving a message.  It's really the object that
>> *would* be, or will be, or could be the receiver.
>
> and also:
>> I'll add that, though it's a subtle point, I don't think that objects
>> receive methods. They receive messages, and act on the basis of those
>> messages (execute a like-named method or method_missing, or raise an
>> exception).
>
> I don't recall any suggestion that objects receive 'methods'.
> I've tried to use the standard 'messages are sent to objects' terminology.
>
> I'm not sure why you view the object bound to a Method instance as
> somewhat conditional.  The only way that that object would not be
> the receiver (i.e. the object identified as self when the bound method
> body executes) is if Method#call itself was never executed.

I don't view the binding as conditional; I just don't think the word
"receiver" describes the binding.  Also, your second sentence is
exactly my point: there is a perfectly plausible scenario where the
object would *not* be the receiver.

> At the point that a Method instance is created, the lookup process
> that maps a message to a method definition has already been triggered.
> Later on, when Method#call gets executed, there is no need for the method
> lookup process to run again.  The message is 'sent' to the object at
> the time Kernel#method is executed and not at the time that Method#call
> is executed.

I don't think that's right.  Sending a message to an object means (or
always has meant) asking the object to find and execute a method with
a matching name.  What you're doing here is a different operation.

Going back to basics:

   a.x
   a.send(:x)

In these two statements, a is receiving the message x.  That doesn't
happen when you do this:

   a.method(:x)

or this:

   a.respond_to?(:x)

etc.  You're answering questions related to the receipt of x by a, but
a is not receiving x.

> It is only the actual execution of the method body that
> remains to be completed at some point in the future.  It seems a lot more
> definite to me than your 'would/will/could' description although I
> certainly agree that the final step might never be taken, but that is
> also true of things like different branches of an if/else or case
> statement.

Right -- and here:

   if false
     a = 3
   end

I would not describe a as equal to 3 :-)

Actually, this:

   a.method(:x).call

is in a sense a way to arrange for a *not* to receive the message x,
but to execute x in a different way.  So "receiver" doesn't even
really become relevant if the method gets called.  a is really a kind
of un-receiver.


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)