On 9/1/06, Phrogz <gavin / refinery.com> wrote:
> > irb(main):001:0> load 'moddefining.rb'
> > => true
> > irb(main):002:0> String.module_defining('==')
> > => String
> > irb(main):003:0> String.module_defining('id')
> > => Kernel
> > irb(main):004:0> String.module_defining('map')
> > => Enumerable
>
> Sexy! :)
>
> IMO something like this would make a nice addition to the core library.
> Jumping through hoops for introspection is no fun. (At least this one
> doesn't involve any string parsing.)
>
> Note that the Method#inspect method gives you this same information in
> string form:
>
> irb(main):001:0> "".method( :== )
> => #<Method: String#==>
> irb(main):002:0> String.instance_method( :== )
> => #<UnboundMethod: String#==>
> irb(main):003:0> "".method( :id )
> => #<Method: String(Kernel)#id>
> irb(main):004:0> String.instance_method( :id )
> => #<UnboundMethod: String(Kernel)#id>
> irb(main):005:0> "".method( :map )
> => #<Method: String(Enumerable)#map>
> irb(main):006:0> String.instance_method( :map )
> => #<UnboundMethod: String(Enumerable)#map>
>
> Less or more reliable to use this with string parsing? Perhaps slightly
> more, if only to be sure that the method resolution order is properly
> followed.

Well although the ri documentation for Module#included_modules doesn't
say wo in so many words, it does in fact produce the list in the right
order.

The way an included module is implemented is that a 'hidden' proxy
class is inserted  between the class which includes the module, and
it's superclass.  It's hidden because it's marked as being a T_ICLASS.

The included_modules C code just walks the chain from the super class
and the superclass of the class, listing any T_ICLASSes that it finds.

Since this is the way that method lookup works, it's exactly the right order.
-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

IPMS/USA Region 12 Coordinator
http://ipmsr12.denhaven2.com/

Visit the Project Mercury Wiki Site
http://www.mercuryspacecraft.com/