transfire / gmail.com wrote:
> What _was_ suggested though, is that the "class-level" of a module
> might be more appropriately a "module-level". Classes would still have
> class-levels, but by giving modules their "own kind" in this role, the
> difficulty of extending a class via a module's "module-level" is easily
> solved --a solution which is the hope of this thread. And such a
> solution, I reitererate, does not in any way constitute MI.

I agree with you throughout the post, and I do enjoy being called Mr. 
Schierbeck (we seldom use such formalities where I am from,) but I'm 
still not sure if we have the same idea about the "module-level". Are 
you suggesting we replace module objects' singleton classes with such a 
"module-level", or would the singleton methods and constants be defined 
in both?

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. I agree with you that 
multiple inheritance would mean a non-linear line of inheritance, and 
that allowing Class objects to be included would not have such a 
consequence. Basically, I think module authors should be able to write this:

   module MyModule
     def self.included(mod)
       mod.extend(class << self; self; end)
     end

     def self.foo
       "a class method"
     end

     def bar
       "an instance method"
     end
   end

   class Test
     include MyModule
   end

   Test.foo      #=> "a class method"
   Test.new.bar  #=> "an instance method"

I think module authors should be able to make that decision (as they do 
now, with the hacks and all.) 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

(geez, it sure would be nice with a shorthand for singleton classes...)


Cheers,
Daniel