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.

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. 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.

class A
   def foo; 'class A; end
end

a = A.new
m1 = a.method 'foo'

def a.foo
   'singleton method'
end

m2 = a.method 'foo'

m1.call   # 'class A'
m2.call   # 'singleton method'

One interesting thing that I noticed is that you can't capture
a potential use of 'method_missing' with Kernel#method:

class A
   def method_missing(sym)
     'gotcha'
   end
end

m1 = A.new.method 'foo'    # NameError
A.new.foo                  # gotcha

It seems like Kernel#method should bind the method_missing
implementation to an instance of Method.

I certainly agree with you that the situation calls for some careful
thought with respect to the naming and terminology. It is easy to
get lost in the multiple layers of context that are inherent in things
like Method and UnboundMethod.


Gary Wright