[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: Minor Change Proposal for Classes 'Object' and 'Method'

Yukihiro Matsumoto

1/23/2007 12:47:00 AM

Hi,

In message "Re: Minor Change Proposal for Classes 'Object' and 'Method'"
on Tue, 23 Jan 2007 09:14:28 +0900, dblack@wobblini.net writes:

|I don't know, in terms of the other languages. I don't think it's
|exactly analogous, though. It's really a bound object, so
|bound_object would probably be the most straightforward.

The term 'bound_object' is not suitable for the Method object model in
my brain. I want to retrieve the object corresponding to self in that
method. Among your suggestions, "target" is better than bound_object.
But I still fond of 'receiver'.

|I've also started thinking about the idea of a MethodData class... but
|it's pretty unformulated.

Hmm, I am looking forward.

matz.

22 Answers

Ara.T.Howard

1/23/2007 12:54:00 AM

0

dblack

1/23/2007 1:04:00 AM

0

dblack

1/23/2007 1:10:00 AM

0

WoNáDo

1/23/2007 1:15:00 AM

0

dblack@wobblini.net schrieb:
> md = str.method_data(:split) => MatchData object

I Think its a typo - you mean "=> MethodData object" !?

Wolfgang Nádasi-Donner

dblack

1/23/2007 1:18:00 AM

0

Ara.T.Howard

1/23/2007 2:45:00 AM

0

Gary Wright

1/23/2007 4:23:00 AM

0


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

Gary Wright




dblack

1/23/2007 11:38:00 AM

0

dblack

1/23/2007 11:55:00 AM

0

Pit Capitain

1/23/2007 3:50:00 PM

0

Robert Dober schrieb:
> On 1/23/07, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
>> 'receiver' makes perfect sense to me. so does 'this'.
>
> it does not make sense to me, it is only a potential receiver at the time
> being, the receiver in a Bound Method object is just not a meaningful term.
> In order to receive a message a message must be sent.

To me, the main point of this discussion so far has been whether we
should call an object a receiver if it only plays the *role* of a
receiver but hasn't *acted* as a receiver yet. David et al. think this
would be misleading, others (me included) don't think so. We could go on
and on and I don't think we'll come to an agreement.

But is it really true, that after

m = a.method(:x)

the object "a" hasn't acted as a receiver yet? Look at this code:

class C
def x
"x of #{self}"
end
end

a = C.new
m = a.method(:x)

The method C#x hasn't been executed yet. Let's do it in two ways:

puts a.x # => x of #<C:0x2ae912c>
puts m.call # => x of #<C:0x2ae912c>

Now we change the implementation of the method:

class C
remove_method(:x)
def x
"new x of #{self.inspect}"
end
end

puts a.x # => new x of #<C:0x2ae912c>
puts m.call # => x of #<C:0x2ae912c>

The BoundMethod object "m" still uses the old definition. Even after
removing the method...

class C
remove_method(:x)
end

puts a.x rescue puts $! # => undefined method `x' for #<C:0x2ae912c>
puts m.call # => x of #<C:0x2ae912c>

...we are still able to execute the old implementation. So, if I look at
this example, I don't think that

m.call

is really sending a message. It just executes the implementation it has
remembered in the context of the original object.

What happens when an object receives a message?

1) Search a method for the message in the object's classes/modules.
2) Execute this method in the context of the object.

If the steps 1) and 2) are separated as in...

m = a.method(:x)
m.call

...I would even say that the receiving part has occurred in step 1),
where the object decides how it wants to react upon the message. In step
2), the object's role is to execute a given piece of code in its context.

So, I would say that after

m = a.method(:x)

the object a has at least partly acted as a receiver.

David, could you live with that? :-)

Regards,
Pit