From: Daniel Schierbeck Date: 2006-06-13T17:21:26+09:00 Subject: Re: Why the lack of mixing-in support for Class methods? 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