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)