Hi -- On Mon, 22 Jan 2007, gwtmp01 / mac.com wrote: > > On Jan 21, 2007, at 8:19 PM, dblack / wobblini.net wrote: >> But what does: >> >> m = a.method(:x) >> >> represent -- *without* making the call to the method? At that point, >> there has been no event (direct or indirect) where a has received "x". >> All we've done is create a Method object, based on a's interface. The >> only message-receiving is a receiving "method", but not "x". > > In my mind, the Method instance represent that future event. It is > a model of a Ruby concept (which has no concise name): the final delivery > of a message to an object. And at the point that the message is finally > delivered (i.e. the chuck of code is executed) isn't it reasonable to say > that the object has 'received' the message (:x) and so it is the 'receiver'? > Of course my answer is 'yes' and since I view a Method instance as modeling > that future event, using 'receiver' as the accessor is not confusing > *to me*. I understand what you mean about the future event, but I'm still not getting why it wouldn't be better to model what's happening *now*. Why the imperative to skip over that part? What would be lost if the object bound to the method were referred to as the object bound to the method, rather than the receiver of a message it hasn't received? In general I think it's important to keep the phases -- message receiving, method lookup, method execution -- conceptually separate. Not in informal discussion, perhaps, but definitely in available terminology. Otherwise one ends up having to back-pedal in order to explain method_missing, class/module order, etc. > Perhaps the class shouldn't be called Method but instead MethodInvocation or > BoundMethodInvocation (and UnboundMethodInvocation of course). Maybe the > shortened versions omit too much of the context? Something does :-) 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)