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


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?

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

Gary Wright