
Submitted by rdenatale (Mon Sep 04 17:13:39 UTC 2006)
The actual implementation returns the list in the order in which the modules are searched for methods at runtime. Making this order explicit would be useful.
The 1.8 implementation of included_modules basically walks the chain of 'classes' between the superclass of the module/class in question, and the 'superclass' of it's class, looking for 'classes' marked with a type of T_ICLASS. The word 'class' is in quotes here because in some cases, these are not visible Ruby classes but rather virtual or proxy classes.
The net effect of this implementation is that the list of included modules is the same as the run-time search order for methods.
It would be useful for such metaprogramming code if this feature was documented so that it would not be changed in future versions of Ruby without consideration.
The documentation in question is the rdoc comment in class.c just before the C function rb_mod_included_modules, I would propose that this be changed to something like:
/*
* call-seq: * mod.included_modules -> array * * Returns the list of modules included in <i>mod</i>. * The elements of this list are in the order in which * modules are examined in finding a method for mod, * that is, they are in the reverse chronological order * in which the modules were included. * * module Mixin * end * * module Mixin2 * end * * module Outer * include Mixin * include Mixin2 * end * * Mixin.included_modules #=> [] * Outer.included_modules #=> [Mixin2, Mixin] */

| Comments | Current voting | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|


RCRchive copyright © David Alan Black, 2003-2005.
Powered by Ruby on Rails.