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)