I would like to make a small change suggestion on the class 'Method' by which the method 'Object#method' is also affected.
Background:
___________
When creating a 'Method' object, it is not possible to receive the object identification of the object which uses the 'Object#method' method (see 'Example for Workaround' for details) by using some Method of class 'Method'.
It is useful for some applications to analyse later on which to which objects a method is bound in an object of class 'Method'. In addition, it is simply missing from my viewpoint, because it is an essential information (attribute) of an object of class 'Method'.
A minor wish is an additional method for class 'Method', which returns the contents of 'Method#to_s' as an Array containing two elements, the class-name and the method-name without the textual border of 'Method#to_s'. It is easier and less expensive to return this existing information by a method of class 'Method', than to use a regular expression later on to extract the information.
The method names used by here are only suggestions, since I needed names for the example. Regarding definite names I have no emotions.
___________
>>>>> Example for Workaround >>>>>
class Object
alias :_org_method :method
def method(name)
method_object = self._org_method(name)
method_object.instance_id = self.object_id
method_object
end
end
class Method
attr_accessor :instance_id
def method_name
md = self.to_s.match(/Method:\s*([^#]+)#([^>]+)>/)
return md[1], md[2]
end
end
# Now an example
class Hugo
def hi
puts "An instance of Hugo says 'Hi!'"
end
end
my_hugo = Hugo.new
puts my_hugo.object_id # => 22497820 (for example)
myhi = my_hugo.method(:hi)
myhi[] # => An instance of Hugo says 'Hi!'
puts myhi.instance_id # => 22497820 (for example)
p myhi.method_name # => ["Hugo", "hi"]
>>>>> End of Example >>>>>
___________
Please inform me, if this is not the right place for a change proposal.
Minor Change Proposal for Classes 'Object' and 'Method'
my_hugo = Hugo.new
puts my_hugo.object_id # => 22497820 (for example)
myhi = my_hugo.method(:hi)
myhi # => An instance of Hugo says 'Hi!'
puts myhi.instance_id # => 22497820 (for example)
p myhi.method_name # => ["Hugo", "hi"]
Why object_id? Isn't it more useful to return the receiver itself,
e.g.
myhi.receiver # => #<Hugo:0xb7d5ff40>
?
And why should method_name return combination of class name and method
name? I think the method_name should return the method name only
("hi" for this case). It may be useful to implement separate method
to get a class that holds the method.
matz.
···
In message "Re: Minor Change Proposal for Classes 'Object' and 'Method'" on Sat, 20 Jan 2007 01:15:05 +0900, Wolfgang Nádasi-Donner <wonado@donnerweb.de> writes:
I don't know where to put this message into the very large discussion tree, so I will put it here.
There is an argument against naming a method "receiver", which returns the object which was bound to a method object.
>>>>> Example >>>>>
class Otto
def hi
puts "'Hi!' from an 'Otto' instance (#{self.inspect})"
end
end
class Hugo < Otto
def hi
puts "'Hi!' from an 'Hugo' instance (#{self.inspect})"
end
end
o = Otto.new
h = Hugo.new
bo = o.method(:hi)
bh = bo.unbind.bind(h)
h.hi # => 'Hi!' from an 'Hugo' instance (#<Hugo:0x2aea4dc>)
bh.call # => 'Hi!' from an 'Otto' instance (#<Hugo:0x2aea4dc>)
bo.call # => 'Hi!' from an 'Otto' instance (#<Otto:0x2aea478>)
>>>>> EoE >>>>>
In this example, the "Method" object "bh" contains (I temporary use this wording for this example) the object "h", and the method "Otto#hi", which can be seen in the output of "bh.call" - but - if ones sends the message "hi" to the object "h" the method "Hugo#hi" will be used (see output for "h.hi").
This means, that for the object "h" contained in "Method" object "bh" a message "hi" will not end up in calling "Otto#hi", because it finds "Hugo#hi".
It is misleading to call "h" the "receiver" of a message, that leads to the invocation of "Otto#hi", because this cannot be done by any message in this example.
May be a different name is better to avoid confusion.
I don't know how you handle "Change Proposals" for Ruby. Implement them silently or write somewhere an announcement, so I try to summarize what happens, as I understood it.
Please correct me if I'm wrong, because I will report about the results in the german Ruby forum.
I include my proposal for class "UnboundMethod" here, because I think it is strongly related to this one.
···
----------------------------
As I understood, the will be some new methods available now or in the near future in the repository (or the nightly snapshot). I'm not sure about the chosen names, so please correct them.
==============
Class "Method"
Public instance Methods:
receiver
--------
"receiver" returns the bound object of the method object. E.g. for "mo = o.method(:m)" the expression "mo.receiver" will return "o".
name
----
"name" returns the name of the method object. E.g. for "mo = o.method(:m)" the expression "mo.name" will return ":m" (symbol) or "'m'" (string).
owner
-----
"owner" returns the class which holds the method. E.g. for "mo = o.method(:m)" the expression "mo.owner" will return "c", if the method ":m", that is bound to "mo", is defined in this class. If the class is an anonymous class, it will be handled correctly.
=====================
Class "UnboundMethod"
Public instance Methods:
name
----
"name" returns the name of the method object. E.g. for "mo = o.method(:m)" the expression "mo.name" will return ":m" (symbol) or "'m'" (string).
owner
-----
"owner" returns the class which holds the method. E.g. for "mo = o.method(:m)" the expression "mo.owner" will return "c", if the method ":m", that is bound to "mo", is defined in this class. If the class is an anonymous class, it will be handled correctly.
-----------------------
Is it a correct summary. There are so many messages in the discussion, that I ended up in comfusion about the chosen names, sorry.
Why object_id? Isn't it more useful to return the receiver itself,
e.g.
myhi.receiver # => #<Hugo:0xb7d5ff40>
?
And why should method_name return combination of class name and method
name? I think the method_name should return the method name only
("hi" for this case). It may be useful to implement separate method
to get a class that holds the method.
I agree, because I'm only interested in the information at all. If you find a better format or better way to present it, its fine.
One question is open for 'myhi.receiver # => #<Hugo:0xb7d5ff40>'.
First, the format requires a pattern matching on the result, if the object-id ist needed only. May be two seperate methods are better, as you suggested for 'method_name'.
In additon, a format for the seperate method, that returns information about the class that holds the method, may be complicated for singleton methods. An example is '#<Method: #<Hugo:0x2ae6e54>.private_hi>'.
And why should method_name return combination of class name and method
name? I think the method_name should return the method name only
("hi" for this case).
I agree here. Furthermore I think that #name would be a better name, in
analogy to Module#name.
Why object_id? Isn't it more useful to return the receiver itself,
e.g.
myhi.receiver # => #<Hugo:0xb7d5ff40>
?
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.
matz.
···
In message "Re: Minor Change Proposal for Classes 'Object' and 'Method'" on Sat, 20 Jan 2007 01:52:36 +0900, Yukihiro Matsumoto <matz@ruby-lang.org> writes:
On Jan 19, 2007, at 12:33 PM, Yukihiro Matsumoto wrote:
Hi,
In message "Re: Minor Change Proposal for Classes 'Object' and > 'Method'" > on Sat, 20 Jan 2007 01:52:36 +0900, Yukihiro Matsumoto > <matz@ruby-lang.org> writes:
>Why object_id? Isn't it more useful to return the receiver itself,
>e.g.
>
> myhi.receiver # => #<Hugo:0xb7d5ff40>
>
>?
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?
object.where? "method_name" # returns nil if not defined
object.definer "method_name" # same as above
another idea:
m = object.def "method_name" # an uber-bound method object
p m.name #=> "method_name"
m.call *a, &b #=> same as object.method_name *a, &b
kind regards.
-a
···
On Sat, 20 Jan 2007, Yukihiro Matsumoto wrote:
Hi,
In message "Re: Minor Change Proposal for Classes 'Object' and 'Method'" > on Sat, 20 Jan 2007 01:52:36 +0900, Yukihiro Matsumoto <matz@ruby-lang.org> writes:
>Why object_id? Isn't it more useful to return the receiver itself,
>e.g.
>
> myhi.receiver # => #<Hugo:0xb7d5ff40>
>
>?
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.
--
we can deny everything, except that we have the possibility of being better.
simply reflect on that.
- the dalai lama
>Why object_id? Isn't it more useful to return the receiver itself,
>e.g.
>
> myhi.receiver # => #<Hugo:0xb7d5ff40>
>
>?
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.
Method#parent
Dan
···
In message "Re: Minor Change Proposal for Classes 'Object' and 'Method'" > on Sat, 20 Jan 2007 01:52:36 +0900, Yukihiro Matsumoto <matz@ruby-lang.org> writes:
>Why object_id? Isn't it more useful to return the receiver itself,
>e.g.
>
> myhi.receiver # => #<Hugo:0xb7d5ff40>
>
>?
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.
What about origin ? Or even of ?
method.of => MyClass
Cheers,
Vince
···
In message "Re: Minor Change Proposal for Classes 'Object' and 'Method'" > on Sat, 20 Jan 2007 01:52:36 +0900, Yukihiro Matsumoto <matz@ruby-lang.org> writes:
Method#receiver
Method#name
Method#origin # module/class with definition of method
Kernel#origin(name) # module/class where named method is found
# via standard method lookup process on the
# receiver.
# nil if no matching method found
Kernel#origin!(name) # same as origin but reports location of
# any matching method_missing implementation
# nil if no method_missing applies
Not sure about origin vs. origin! names but it seems reasonable
to be interested in whether method_missing is triggered or not.
I've often thought it might be nice to have a 'magic' reference
similar to 'self' that referenced a method object matching the
current receiver and method:
def factorial(n)
return 1 if n.zero?
myself[n-1] * n
end
So in that example, 'myself' would be an instance of Method bound
to the top-level object and the method Object#factorial.
Not sure about the 'myself' name, but I like the idea.
Gary Wright
···
On Jan 19, 2007, at 1:33 PM, Yukihiro Matsumoto wrote:
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.
I opt for "defining_class", because this precisely states what it returns. Some might find it a bit much of typing but I think we have much worse cases in Ruby (attr_accessor for example, which is much more often used). If someone can come up with an equally clear name which is shorter, that's fine with me.
Kind regards
robert
···
On 19.01.2007 19:33, Yukihiro Matsumoto wrote:
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.
>Why object_id? Isn't it more useful to return the receiver itself,
>e.g.
>
> myhi.receiver # => #<Hugo:0xb7d5ff40>
>
>?
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.
···
In message "Re: Minor Change Proposal for Classes 'Object' and 'Method'" > on Sat, 20 Jan 2007 01:52:36 +0900, Yukihiro Matsumoto <matz@ruby-lang.org> writes:
and I need 'eval' to compare the textual presentation of the object-id with the object-id I receive from "Object#object_id" (or I have to convert this result to an textual hex-presentation)
Method#receiver
Method#name
Method#origin # module/class with definition of method
Kernel#origin(name) # module/class where named method is found
# via standard method lookup process on the
# receiver.
# nil if no matching method found
> 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.
I opt for "defining_class", because this precisely states what it
returns. Some might find it a bit much of typing but I think we have
much worse cases in Ruby (attr_accessor for example, which is much more
often used). If someone can come up with an equally clear name which is
shorter, that's fine with me.
I have two objections to this:
1) The fact that there are some methods which are a pain to type does
not mean that we should feel OK about making all methods a pain to
type. Certainly, verbose naming matters less of the method would be
infrequently used (as this one would). But we should continually strive
for a balance between clarity and terseness (and I see that you
implicitly agree with that, given your last sentence).
2) If a method is rebound to a new object, what is desired (I think) is
the current 'parent' class of the method, not the one where it was
defined. If derivatives of the word 'defined' are in the method name,
this (edge) case will be confusing.
If we're going verbose, I prefer #owning_class. Striving for terseness,
however, I prefer #owner. To me, that's pretty clear.