On 20.01.2007 20:30, Vincent F. wrote:
[email protected] wrote:
Right, but I don’t see that relationship as the same as what we
usually call “receiver”, which is part of the dynamic process of an
object actually receiving a certain message.What about ‘target’, then ? It shows that it is not necessary the
receiver, but that it has been considered as a potential one.
Go for it! “target” sounds perfect to me.
Now, what do we do about the class method? 
Kind regards
robert
Hi –
On Sun, 21 Jan 2007, [email protected] wrote:
exception).
I don’t recall any suggestion that objects receive ‘methods’.
I’ve tried to use the standard ‘messages are sent to objects’ terminology.I’m not sure why you view the object bound to a Method instance as
somewhat conditional. The only way that that object would not be
the receiver (i.e. the object identified as self when the bound method
body executes) is if Method#call itself was never executed.
I don’t view the binding as conditional; I just don’t think the word
“receiver” describes the binding. Also, your second sentence is
exactly my point: there is a perfectly plausible scenario where the
object would not be the receiver.
At the point that a Method instance is created, the lookup process
that maps a message to a method definition has already been triggered.
Later on, when Method#call gets executed, there is no need for the method
lookup process to run again. The message is ‘sent’ to the object at
the time Kernel#method is executed and not at the time that Method#call
is executed.
I don’t think that’s right. Sending a message to an object means (or
always has meant) asking the object to find and execute a method with
a matching name. What you’re doing here is a different operation.
Going back to basics:
a.x
a.send(:x)
In these two statements, a is receiving the message x. That doesn’t
happen when you do this:
a.method(:x)
or this:
a.respond_to?(:x)
etc. You’re answering questions related to the receipt of x by a, but
a is not receiving x.
It is only the actual execution of the method body that
remains to be completed at some point in the future. It seems a lot more
definite to me than your ‘would/will/could’ description although I
certainly agree that the final step might never be taken, but that is
also true of things like different branches of an if/else or case
statement.
Right – and here:
if false
a = 3
end
I would not describe a as equal to 3
Actually, this:
a.method(:x).call
is in a sense a way to arrange for a not to receive the message x,
but to execute x in a different way. So “receiver” doesn’t even
really become relevant if the method gets called. a is really a kind
of un-receiver.
David
Hi –
On Sun, 21 Jan 2007, Wolfgang Nádasi-Donner wrote:
a.respond_to?(:x)
I think “a” receives the message “x” only in the first case. The second one
means ‘“a” receives the message “send” and the parameter “:x”’.
Yes, I agree, though I still think it’s reasonable to say that, as a
result of the send operation, a receives the message :x. In any case,
I included it because it demonstrates that there’s a “meta” or
two-step way of getting a message to an object, but that a.method(:x)
isn’t such a technique.
David
[email protected] schrieb:
In any case,
I included it because it demonstrates that there’s a “meta” or
two-step way of getting a message to an object, but that a.method(:x)
isn’t such a technique.
“mo = a.method(:x)” creates a new object “mo” of class “Method”, which
contains
the object “a” and a reference (or however to name this) to a method. To
find
the method, “:x” will be interpreted as a message “x” to object “a”, but
the
corresponding method will not be executed, but referenced in the new
Method object.
When writing “mo.call” the object “a” will be enforced to use the method
referenced by “mo” without any method lookup. This means, that the
actual state
of object “a” will be used to call a method, which may be overwritten in
the
meantime.
The name “receiver” for a method of class “Method”, which returns the
object for
which “method” was called makes some sense, because in the moment
“method” was
called, the referenced method inside the “Method” object would be
executed by
the object when receiving the message named by the parameter for the
“method”
method.
Code >>>>>
class Otto
attr_accessor :id
def hi
puts “‘Hi!’ from an instance of ‘Otto’ with id #{self.id}”
end
def initialize(id)
self.id = id
end
end
otto = Otto.new(42)
myhi = otto.method(:hi)
otto.hi # => ‘Hi!’ from an instance of ‘Otto’ with id 42
myhi.call # => ‘Hi!’ from an instance of ‘Otto’ with id 42
class Otto
def hi
puts “‘Hihihi!’ from an instance of ‘Otto’ with id #{self.id}”
end
end
otto.id = 84
otto.hi # => ‘Hihihi!’ from an instance of ‘Otto’ with id 84
myhi.call # => ‘Hi!’ from an instance of ‘Otto’ with id 84
class Otto
remove_method :hi
end
myhi.call # => ‘Hi!’ from an instance of ‘Otto’ with id 84
otto.hi # => MethodSuchReihe.rb:33: undefined method `hi’ for
# => #<Otto:0x2ae9af0 @id=84> (NoMethodError)
EOC >>>>>
Wolfgang Nádasi-Donner
[email protected] schrieb:
a.respond_to?(:x)
I think “a” receives the message “x” only in the first case. The second
one
means ‘“a” receives the message “send” and the parameter “:x”’. The rest
is
similar with messages “method” and “respond_to?”, both with parameter
“:x”.
It’s up to the actions that will be startet to handle the parameter
“:x”.
Wolfgang Nádasi-Donner
Hi –
On Mon, 22 Jan 2007, Wolfgang Nádasi-Donner wrote:
in the new Method object.
I think we’re talking past each other.
When writing “mo.call” the object “a” will be enforced to use the method
referenced by “mo” without any method lookup. This means, that the actual
state of object “a” will be used to call a method, which may be overwritten
in the meantime.The name “receiver” for a method of class “Method”, which returns the object
for which “method” was called makes some sense, because in the moment
“method” was called, the referenced method inside the “Method” object would
be executed by the object when receiving the message named by the parameter
for the “method” method.
That’s all correct, but the word “receiver” doesn’t communicate it to
me. Given this:
m = a.method(:x)
I do not consider it optimal to describe a as m’s “receiver”. It’s a
re-definition of the term, and I think it would lead to confusion.
That doesn’t mean that there’s no relationship between m and a. It
just means that the word “receiver” isn’t the right word to describe
that relationship. I’d rather see:
m.target
m.bound_object
etc. – something other than m.receiver.
David
[email protected] schrieb:
That doesn’t mean that there’s no relationship between m and a. It
just means that the word “receiver” isn’t the right word to describe
that relationship. I’d rather see:m.target
m.bound_objectetc. – something other than m.receiver.
I see - I’m not used to use often English since a while, so these
details were
not visible for me.
It is better that native english speakers will define the names.
But now I’m really interested in the names, the methods will have in the
implementation.
Wolfgang Nádasi-Donner
On 1/21/07, Wolfgang Nádasi-Donner [email protected] wrote:
I see - I’m not used to use often English since a while, so these details
were
not visible for me.It is better that native english speakers will define the names.
But now I’m really interested in the names, the methods will have in the
implementation.
I do not want to play the wise guy, but what David said took me a very
long
time to understand and yet seems so simple now.
Normally the stupid one having understood can explain much better,
forgive
me for the blunt try:
A method just does not have a receiver, that is completely correct.
A message sent to a receiver may trigger a method which than is called
with
the receiver.
A method bound to an object (and I will not define the name 
of course
is
a very likely receiver of a message triggering an eventual call of the
bound
method.
Confusing? or did I get it wrong?
Cheers
Robert
Wolfgang Nádasi-Donner
Hi,
In message “Re: Minor Change Proposal for Classes ‘Object’ and ‘Method’”
on Mon, 22 Jan 2007 02:03:35 +0900, [email protected] writes:
|That’s all correct, but the word “receiver” doesn’t communicate it to
|me. Given this:
|
| m = a.method(:x)
|
|I do not consider it optimal to describe a as m’s “receiver”. It’s a
|re-definition of the term, and I think it would lead to confusion.
“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.
matz.Hi –
On Mon, 22 Jan 2007, Yukihiro M. wrote:
|I do not consider it optimal to describe a as m’s “receiver”. It’s a
|re-definition of the term, and I think it would lead to confusion.“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.
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.
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.
I don’t know – it just seems that with so many words available, it’s
better not to re-use a word that’s not a complete fit, even if it’s
related to the same problem domain.
David
Hi,
In message “Re: Minor Change Proposal for Classes ‘Object’ and ‘Method’”
on Mon, 22 Jan 2007 09:27:28 +0900, [email protected] 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.On Jan 21, 2007, at 6:50 AM, [email protected] wrote:
if false
a = 3
endI would not describe a as equal to 3
Sure but I think you’ve confused the issue a bit by using assignment,
which isn’t a method call. If we consider:
if rand > 0.5
a.reverse
end
Isn’t it fair to say that ‘a’ is the receiver of the ‘reverse’ message
even though half the time the message will never be sent?
Actually, this:
a.method(:x).call
is in a sense a way to arrange for a not to receive the message x,
but to execute x in a different way. So “receiver” doesn’t even
really become relevant if the method gets called. a is really a kind
of un-receiver.
This one, really has me scratching my head. Certainly there is a method
body that gets invoked by ‘a.method(:x).call’ and during the
execution of
that method body, self and ‘a’ will reference the same object. Isn’t it
fair to say then that ‘a’ (or more accurately the object referenced by
‘a’) is the receiver of the message that caused the method body to
be invoked? The fact that the lookup of the method body for message
‘x’ is separated in time from the execution of the method body doesn’t
really change the fact that ‘a’ is the receiver of the message, does it?
I’m using ‘method body’ to be clear that I’m not talking about an
instance
of Method.
Gary W.
Hi –
On Mon, 22 Jan 2007, Yukihiro M. wrote:
|
|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.
What I mean is: the object becomes a receiver because it actually
receives a message. a.method(:x) tells us that a has an “x” method,
but it does not actually involve a set of events where a plays the
role “receiver”.
|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.
Yes… but this is a different scenario. I think it’s important for
the terminology to reflect that. It’s true that if obj.method(:x)
exists, then obj responds to “x” and can receive “x”. But it’s still
separate things.
|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.
But when you do: a.method(:x), there’s no self in a#x because a#x has
not been called.
m = a.method(:x)
m.call(args)
(Is that thread-safe?
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.
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”.
David
On Jan 21, 2007, at 8:27 PM, [email protected] wrote:
I’m using ‘method body’ to be clear that I’m not talking about an
instance
of Method.The instance of Method is what’s involved though – that is, whether
it should have a “receiver” method.
Sure, but I wasn’t talking about one or the other but the
relationship between
the two. I couldn’t just call them both ‘method’ because that would
be confusing
so I called one ‘method body’ and the other ‘instance of method’. I
was trying to
be clear and I’m not aware of any particular standard terminology for
these things
so I picked ‘method body’. Other choices might have been ‘method
definition’ or,
if you like looking at the internals, a C pointer to a METHOD struct.
Gary W.
Hi –
On Mon, 22 Jan 2007, [email protected] wrote:
Right – and here:
if rand > 0.5
is in a sense a way to arrange for a not to receive the message x,
‘x’ is separated in time from the execution of the method body doesn’t
really change the fact that ‘a’ is the receiver of the message, does it?
But it’s exactly that separation in time that’s critical:
m = a.method(:x)
m.call # This may or may not happen; it’s not relevant to the
# question of whether the relation between m and a is
# that a is the “receiver” of m.
I’m using ‘method body’ to be clear that I’m not talking about an instance
of Method.
The instance of Method is what’s involved though – that is, whether
it should have a “receiver” method.
David
Hi,
In message “Re: Minor Change Proposal for Classes ‘Object’ and ‘Method’”
on Mon, 22 Jan 2007 10:19:07 +0900, [email protected] writes:
|> 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.
|
|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”.
Ordinary message passing
a.x
does the following steps
(1) retrieve a class of the object a.
(2) look-up method table in a class by name x
(3) if it doesn’t exist, looks for super-class table
(4) invoke a method with self bound to the object a.
whereas
a.method(:x)
does steps 1 through 3, and creates a method object reserved for the
4th step. When we can call the object a in the former sequence a
receiver, what is wrong calling receiver too in the latter sequence,
even though target or bound_object is more accurate. Do you think
possible confusing critical?
matz.Hi –
On Mon, 22 Jan 2007, [email protected] wrote:
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.
I understand what you mean about the future event, but I’m still not
getting why it wouldn’t be better to model what’s happening now.
Why the imperative to skip over that part? What would be lost if the
object bound to the method were referred to as the object bound to the
method, rather than the receiver of a message it hasn’t received?
In general I think it’s important to keep the phases – message
receiving, method lookup, method execution – conceptually separate.
Not in informal discussion, perhaps, but definitely in available
terminology. Otherwise one ends up having to back-pedal in order to
explain method_missing, class/module order, etc.
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?
Something does
David
Hi –
On Mon, 22 Jan 2007, Yukihiro M. wrote:
|But what does:
a.x
a.method(:x)does steps 1 through 3, and creates a method object reserved for the
4th step. When we can call the object a in the former sequence a
receiver, what is wrong calling receiver too in the latter sequence,
even though target or bound_object is more accurate. Do you think
possible confusing critical?
I think the possible confusion can be avoided, so I’d rather avoid it.
If you do this:
m = a.method(:x)
m.call
I can understand saying that a is the receiver of :x (even though it’s
an “exploded” path to message-receiving). But the terminology I don’t
like is saying that a is the “receiver” of m:
m.receiver # a
I’ve always found it very helpful (for myself and others) to keep the
whole sequence very visible (message sending, method lookup, method
execution), and I think that using “receiver” as an attribute of a
method object does a short-circuit in the terminology that makes it
harder to explain and understand.
David
On Jan 21, 2007, at 8:19 PM, [email protected] 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 W.
Yukihiro M. [email protected] writes:
|?
Wolfgang’s proposal can be divided into three methods.
#receiver that returns the bound object of the method object.
#name that returns the name of the method object.
and a method that returns the class which holds the method.Does anybody have good name candidate for the last one? I have
already implemented the first two methods in the local copy of the
repository.
While we are at it, can we please have UnboundMethod#to_proc?
It would greatly help to implement callbacks from class methods.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs