transfire / gmail.com wrote:
> ... Modules are linked via virtual classes. (There are
> some good diagrams of this in the Pickaxe, I believe it's under
> "Classes and Objects").  The idea is then to replace a module's current
> "metaclass" with a virtual class linking in a "metamodule". Anything in
> a module's "class << self" then is defined in this metamodule instead.

All I wanted to know.

>> What I thought would be great about allowing #include and #extend to
>> accept Class objects is that it would make it much easier for a module
>> (or, well, class) author to decide for himself whether or not he wishes
>> to have the module methods included as well.
> 
> Well, one can argue the merits for or against that. But it goes beyond
> the need at hand. The division between module and class I think suits
> Ruby. Allowing classes to be included outright, while not MI
> underthehood, nonetheless appears as such on the surface b/c a class
> than appears to be a child of a more than one class. But having modules
> distinct, it can only be the child of one class and instead agumented
> with extra modular behaviors.

So the functionality of modules repressed in order to preserved their 
secondary nature? Why should we limit the power of modules just so that 
we can say Ruby doesn't allow MI?

I think it's a plus if Ruby had the ability to be *like* an MI language, 
just like it can appear to be functional.


>> This would also allow module "users" to
>> opt-in on the module methods:
>>
>>    class Module
>>      def inherit(*mods)
>>        include *mods
>>        mods.each{|mod| extend(class << mod; self; end)}
>>      end
>>    end
> 
> Yes, I think that's a fair option. And IMHO would say that it's the 2nd
> best choice, behind the ability to specify 'extensible' and
> 'uninheritable' sections in ones modules. I still tend to think that
> the the control is best left to a module itself.

I think the use of sections is annoying -- I'd much rather just define 
in the module whether or not the module methods and constants should be 
included, too. If you only want certain methods to be included, I think 
the nested module approach is better.


>> (geez, it sure would be nice with a shorthand for singleton classes...)
> I agree. I've been toying with "own" and "owner" lately myself.

I still like "metaclass" the best -- it may not be the most precise, but 
it flips off the tongue and keyboard. In the end, it's up to matz; I 
don't don't really care what name it'll get, as long as it's there. 
`class << self; self; end' is not the prettiest piece of code...


Daniel aka Mr. Schierbeck :)