Hi -- On Tue, 23 Jan 2007, gwtmp01 / mac.com wrote: > > On Jan 22, 2007, at 8:04 PM, dblack / wobblini.net wrote >> On Tue, 23 Jan 2007, Yukihiro Matsumoto wrote: >>> |I've also started thinking about the idea of a MethodData class... but >>> |it's pretty unformulated. >>> >>> Hmm, I am looking forward. >> >> I can give you the very basic idea (and that will save me some further >> trouble if you don't like it :-) >> >> str = "abc" >> md = str.method_data(:split) => MatchData object >> >> md.method => Method object >> md.receiver => str >> md.method_name => "split" > > I don't understand why you are adding another level of indirection. Just trying to accomodate the "receiver" label in a context where it seems less confusing. I'm not sold on the MethodData thing by any means. > Take a look at the C code for the Method class. A Method object > already contains pointers to lots of internal information. I think > the original suggestion by Wolfgang really just amounted to exposing > that internal information with suitable names. > > Throughout this conversation I kept getting the nagging feeling that > my mental model of the situation was in some important way different > from your mental model of the situation and so we were coming to different > conclusions. I can't put my finger on exactly what the difference is > but this suggestion re: MethodData just emphasizes that feeling for > me. We are thinking about this differently--I'm just not sure I > can pin it down to exactly where our thinking diverges. I think it's that I see this: a.x and this: m = a.method(:x) m.call as two different ways to achieve the goal of executing x with a as self. In the first, a receives the message "x". In the second -- as I see it -- a does not receive the message "x"; it's a different path, a non-message-receiving path, to the same goal. Therefore, I find the use of "receiver" to describe a in the second case to be counterproductive, because instead of exactly pinning down the role that a is playing in that scenario, it tries to characterize the scenario in terms of the first scenario. I would prefer to find a term that pinpoints exactly what the object a *is* in relation to the method object -- not what it will be if the method is called (also debateable anyway), not what it would have been if we'd done a.x instead, but what it *is*. And saying that a is the "receiver" of the Method object is, I think, ambiguous (it sounds like a is receiving the Method object) and incomplete (it doesn't express, except by a kind of indirect suggestion, what the relation is between the objects a and m). The MethodData idea was an attempt to go sort of in the other direction by abstracting *both* the Method object and its "bindee", to put them on an equal footing. I don't necessarily endorse it, but that was my thinking. 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)