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

Hi --

On Mon, 22 Jan 2007, gwtmp01@mac.com wrote:

>
> On Jan 21, 2007, at 6:50 AM, dblack@wobblini.net wrote:
>> On Sun, 21 Jan 2007, gwtmp01@mac.com wrote:
>>> 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 :-)
>
> Sure but I think you've confused the issue a bit by using assignment, which 
> isn't a method call.  If we consider:
>
>  if rand > 0.5
>    a.reverse
>  end
>
> Isn't it fair to say that 'a' is the receiver of the 'reverse' message
> even though half the time the message will never be sent?
>
>> 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.
>
> This one, really has me scratching my head.  Certainly there is a method
> body that gets invoked by 'a.method(:x).call' and during the execution of
> that method body, self and 'a' will reference the same object.  Isn't it
> fair to say then that 'a' (or more accurately the object referenced by
> 'a') is the receiver of the message that caused the method body to
> be invoked? The fact that the lookup of the method body for message
> 'x' is separated in time from the execution of the method body doesn't
> really change the fact that 'a' is the receiver of the message, does it?

But it's exactly that separation in time that's critical:

   m = a.method(:x)

   # Right here, independently of whether or not m ever gets called,
   # we're starting to talk about m's "receiver", which I
   # think is very confusing terminology.  Objects don't receive
   # methods, this object hasn't even received the message whose
   # name corresponds to this method -- it hasn't even received it
   # indirectly.

   m.call   # This may or may not happen; it's not relevant to the
            # question of whether the relation between m and a is
            # that a is the "receiver" of m.

> I'm using 'method body' to be clear that I'm not talking about an instance
> of Method.

The instance of Method is what's involved though -- that is, whether
it should have a "receiver" method.


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)