Reflection API -- determining methods' origins

I’ve been thinking since yesterday about
#methods and #instance_methods and such.

I don’t see any simple way of determining
whether a method is inherited or mixed in
or whatever. (Singleton methods can be
detected, I think.)

For example, suppose B inherits from A and
mixes in M.

I could do some array subtraction to take
away the methods from A and M… but that
ignores the possibility that they might be
rewritten in B.

What I’m trying for is a reliably way of
determining the methods that are defined
in B
(regardless of whether they may be
hiding methods in a parent).

Am I overlooking something here?

Hal

···


Hal Fulton
hal9000@hypermetrics.com

Hi –

I’ve been thinking since yesterday about
#methods and #instance_methods and such.

I don’t see any simple way of determining
whether a method is inherited or mixed in
or whatever. (Singleton methods can be
detected, I think.)

For example, suppose B inherits from A and
mixes in M.

I could do some array subtraction to take
away the methods from A and M… but that
ignores the possibility that they might be
rewritten in B.

What I’m trying for is a reliably way of
determining the methods that are defined
in B
(regardless of whether they may be
hiding methods in a parent).

Am I overlooking something here?

Have a look at this:

module M
def a
end
end

class A
include M
end

class B
include M
def a
end
end

p M.instance_method(:a)
p A.instance_method(:a)
p B.instance_method(:a)

=>
#<UnboundMethod: M(M)#a>
#<UnboundMethod: A(M)#a>
#<UnboundMethod: B(B)#a>

I think you’d have to parse them stringwise, rather than just compare
them, because this:

M.instance_method(:a) == M.instance_method(:a)

is false (i.e., a different UnboundMethod object gets returned even
from the same module).

David

···

On Sat, 9 Aug 2003, Hal E. Fulton wrote:


David Alan Black
home: dblack@superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav