[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/22/2007 12:57:00 AM

Hi,

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

|> "a.method(:x)" looks up a method corresponding message :x, so that we
|> can invoke the method later. It is more accurate to call it "target"
|> or "bound_method", as you pointed. But I feel like there's a
|> convention to call the target (or self) of a method as a "receiver" in
|> OOP context. Given that context, it's natural to call "a" receiver.
|
|I disagree; I don't think it's natural in context, because "receiver"
|is a dynamic role and the result of a.method(:x) is reflective.

I am not sure the difference between dynamic and reflective.

|method(:x) is more like a variation on respond_to?(:x). Neither of
|them actually puts the object in the receiver role; they just examine
|the current type of the object.

It is a receiver of message that retrieves a method corresponding a
certain message name. The object is a receiver when the method was
invoked by ordinary message sending.

|With Method#receiver, We'd end up saying things like, "obj is the
|receiver of this method", which sounds like a mistake ("method" for
|"message"), and also sounds like obj has actually played the receiver
|role.

Ah, I already say so often. The "receiver" is most quick term for me
to describe "self" in a method.

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

represents

a.x(args)

given that we can invoke the particular method, message "x" passing is
done somewhere in above sequence, and "a" is a receiver of the passing.

matz.

3 Answers

dblack

1/22/2007 1:19:00 AM

0

Gary Wright

1/22/2007 3:21:00 AM

0


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

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?

Gary Wright




dblack

1/22/2007 11:24:00 AM

0