Minor Change Proposal for Classes ‘Object’ and ‘Method’
I would like to make a small change suggestion on the class ‘Method’ by
the method ‘Object#method’ is also affected.
When creating a ‘Method’ object, it is not possible to receive the
identification of the object which uses the ‘Object#method’ method (see
for Workaround’ for details) by using some Method of class ‘Method’.
It is useful for some applications to analyse later on which to which
method is bound in an object of class ‘Method’. In addition, it is
missing from my viewpoint, because it is an essential information
an object of class ‘Method’.
A minor wish is an additional method for class ‘Method’, which returns
contents of ‘Method#to_s’ as an Array containing two elements, the
and the method-name without the textual border of ‘Method#to_s’. It is
and less expensive to return this existing information by a method of
‘Method’, than to use a regular expression later on to extract the
The method names used by here are only suggestions, since I needed names
example. Regarding definite names I have no emotions.
Example for Workaround >>>>>
alias :_org_method :method
method_object = self._org_method(name)
method_object.instance_id = self.object_id
md = self.to_s.match(/Method:\s*([^#]+)#([^>]+)>/)
return md, md
Now an example
puts “An instance of Hugo says ‘Hi!’”
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.
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.
to get a class that holds the method.
I agree, because I’m only interested in the information at all. If you
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
ist needed only. May be two seperate methods are better, as you
In additon, a format for the seperate method, that returns information
class that holds the method, may be complicated for singleton methods.
example is ‘#<Method: #Hugo:0x2ae6e54.private_hi>’.
In message “Re: Minor Change Proposal for Classes ‘Object’ and ‘Method’”
on Sat, 20 Jan 2007 03:05:10 +0900, Kalman N. [email protected]
|> 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 you elaborate? Where do you need pattern matching here?
I think he supposed receiver returns above string, but it doesn’t. It
returns the object reference. If you need object-id, you can get it
I don’t think it works well with “Kernel#origin(name)” because the
may change when changing the class definitions. The method, which
class name, should be directly related to the existing “Method” object.
puts “‘Hi!’ from an Otto instance”
class Hugo < Otto
o1 = Hugo.new
mymeth1 = o1.method(:hi)
class Hugo < Otto
puts “‘Hi!’ from a Hugo instance”
mymeth2 = o1.method(:hi)
mymeth1 # => ‘Hi!’ from an Otto instance
mymeth2 # => ‘Hi!’ from a Hugo instance
p mymeth1 # => #<Method: Hugo(Otto)#hi>
p mymeth2 # => #<Method: Hugo#hi>
On Jan 20, 2007, at 10:20 AM, Wolfgang Nádasi-Donner wrote:
I vote for the last one too !
An additional method “Kernel#origin(name)” will be helpful, if the
method is defined as a singleton method for an object, it is
difficult to get the object_id of the anonymous class, where the
method ist defined (I hope this sentense is somehow understndable).
The object_id is necessary in comparisons with the result of the
call to the method of class “Method”, that returns the associated
I was assuming that Method#origin and Kernel#origin would both
return a reference to the class/module. In fact, Kernel#origin
is really just short for method(name).origin and of course
you can just call object_id on the module/class reference as needed.
It appears that you are viewing the (proposed) return value of
Method#origin and Kernel#origin as a string and not as a reference
to the module/class itself as intended by myself and the other
The object_id is necessary in comparisons with the result of the call
Sorry, I am a little bit confused in the moment…
What I like to say is, that in case of
o = Otto.new
my1 = o.method(:hi) # Class Otto, Method hi
class << o
my2 = o.method(:hi) # Class -anonymous-, Method hi
“Method#origin” returns the object_id of the class where the method
Thats clear for me. The problem I see is, that for the second
“my2” “Method#origin” returns an object_id on an anonymous class.
If later on I want to find out if my Method objects reference a method,
defined in an anonymous class, I will have problems to get the object_id
anonymous class without an additional “Kernel#origin(name)” method, that
the object_id of the anonymous class in case of (e.g) “o.origin(:hi)”.
result should not be the same before and after “class << o”.
An additional method “Kernel#origin(name)” will be helpful, if the method is
defined as a singleton method for an object, it is difficult to get the
object_id of the anonymous class, where the method ist defined (I hope this
sentense is somehow understndable).
Could you explain what you mean by this? I would assume that this would
class Foo; def bar1; end; end
f = Foo.new
def f.bar2; end
o1 = f.method( :bar1 ).owner
o2 = f.eigenclass # class << f; self; end
o3 = f.method( :bar2 ).owner
p o1 == Foo
p o2 == o3
The owner of an instance method should be the class on which it is
defined, right? Thus, the owner of a ‘singleton method’
(eigenmethod(?)) would be the (anonymous/singleton/eigen) class. That
would make it easy to get the object_id of that class for the such a