Asp Forum - Re: Minor Change Proposal for Classes 'Object' and 'Method'

Yukihiro Matsumoto

1/19/2007 6:34:00 PM

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.

matz.

46 Answers

Brad Ediger

1/19/2007 6:41:00 PM

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?

I'm kind of partial to #owner myself.

Ara.T.Howard

1/19/2007 7:47:00 PM

Daniel Berger

1/19/2007 7:51:00 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? I have
> already implemented the first two methods in the local copy of the
> repository.

Method#parent

Dan

Vincent Fourmond

1/19/2007 8:02:00 PM

Gary Wright

1/19/2007 8:38:00 PM

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.

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.

Combined with the other proposed methods you get:

myself.name # => 'factorial'
myself.receiver # => main
myself.origin # => Object

Not sure about the 'myself' name, but I like the idea.

Gary Wright

Vincent Fourmond

1/20/2007 12:09:00 AM

gwtmp01@mac.com wrote:
> 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

I vote for the last one too !

Vince
--
Vincent Fourmond, PhD student
http://vincent.fourmon...

WoNáDo

1/20/2007 10:39:00 AM

Vincent Fourmond schrieb:
> gwtmp01@mac.com wrote:
>> 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
>
> I vote for the last one too !
>
> Vince

I don't think it works well with "Kernel#origin(name)" because the lookup result
may change when changing the class definitions. The method, which returns the
class name, should be directly related to the existing "Method" object. Example:

>>>>> Example >>>>>
class Otto
def hi
puts "'Hi!' from an Otto instance"
end
end

class Hugo < Otto
end

o1 = Hugo.new
mymeth1 = o1.method(:hi)

class Hugo < Otto
def hi
puts "'Hi!' from a Hugo instance"
end
end

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>
>>>>> End of Example >>>>>

Wolfgang Nádasi-Donner

WoNáDo

1/20/2007 3:22:00 PM

Vincent Fourmond schrieb:
> gwtmp01@mac.com wrote:
>> 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
>
> I vote for the last one too !
>
> Vince

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

Here is some code as an example for the problem (if I didn't make some
conceptional errors):

class Otto
end
p Otto # => Otto
puts "%x" % Otto.object_id # => 1574ecc
otto = Otto.new
puts "%x" % otto.object_id # => 1574d96
class <<otto
p self # => #<Class:#<Otto:0x2ae9b2c>>
puts "%x" % self.object_id # => 1574d78
def hi
puts "'Hi!' from 'otto'"
end
end
p otto.class # => Otto
puts "%x" % otto.class.object_id # => 1574ecc
p otto.class.superclass # => Object
puts "%x" % otto.class.superclass.object_id # => 15386b6
myottohi = otto.method(:hi)
myottohi[] # => 'Hi!' from 'otto'
p myottohi # => #<Method: #<Otto:0x2ae9b2c>.hi>

Wolfgang Nádasi-Donner

Gary Wright

1/20/2007 3:56:00 PM

On Jan 20, 2007, at 10:20 AM, Wolfgang Nádasi-Donner wrote:

> Vincent Fourmond schrieb:
>> gwtmp01@mac.com wrote:
>>> 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
>> I vote for the last one too !
>> Vince
>
> 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
> class.

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

Gary Wright

WoNáDo

1/20/2007 4:45:00 PM

gwtmp01@mac.com schrieb:
>
> On Jan 20, 2007, at 10:20 AM, Wolfgang Nádasi-Donner wrote:
>
>> Vincent Fourmond schrieb:
>>> gwtmp01@mac.com wrote:
>>>> 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
>>> I vote for the last one too !
>>> Vince
>>
>> 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 class.
>
> 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
> posters.

Sorry, I am a little bit confused in the moment...

What I like to say is, that in case of

class Otto
def hi
puts "Hi"
end
end
o = Otto.new
my1 = o.method(:hi) # Class Otto, Method hi
class << o
def hi
puts "Hihi"
end
end
my2 = o.method(:hi) # Class -anonymous-, Method hi

"Method#origin" returns the object_id of the class where the method belongs too.
Thats clear for me. The problem I see is, that for the second Method-object
"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, that is
defined in an anonymous class, I will have problems to get the object_id of this
anonymous class without an additional "Kernel#origin(name)" method, that returns
the object_id of the anonymous class in case of (e.g) "o.origin(:hi)". The
result should not be the same before and after "class << o".

Wolfgang Nádasi-Donner

comp.lang.ruby

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

Yukihiro Matsumoto

Brad Ediger

Ara.T.Howard

Daniel Berger

Vincent Fourmond

Gary Wright

Vincent Fourmond

WoNáDo

WoNáDo

Gary Wright

WoNáDo

x Login to ForumsZone