From: transfire@... Date: 2006-05-24T02:33:21+09:00 Subject: Closing the Scary Door -- Differentiating Modules from Classes NOTE I originally wrote this back in Aug. '05. I'm taking down my blog, so I just want to put this "on the record". This is purely a theoretical consideration, of course, nontheless I think it's interesting enough to save and share. Thanks. So I've heard Matz considers Ruby's singleton classes an implementation feature, not a design feature. While he wants singleton methods, he doesn't necessarily want the "virtual" classes that currently make them possible. That's interesting. (Ed- I believe he's changed his mind since.) Today I was thinking more about the idea of self-shimmying, which has simple merits in furthering the DRY principle. But as I was exploring a particular avenue in conjuction with this consideration of Matz', I started to see some alternate scenarios for simplifying the class/module design. Currently modules are essentially classes. It is merely by some arbitrary limitations that they differ at all. We really don't need the distinction and could actually get by with classes alone. So I wonder, could modules be more useful if they were truly unique from classes? As it so happens there may be: singleton classes. Rather then use a singleton to represent the "class-level" of a class, use a module. Now even though all modules will be effected by this design change, there is one distinction I'm going to go ahead and make upfront: Modules that serve in place of singleton classes do not need unique names. Instead, they can be referred to via the class or object they "meta" for, so to speak. B/c of this I'll use a keyword 'meta' here, instead of 'module', to clarify the demo of this specific use. meta X def mod_meth ; 'module method' ; end end class X mod_meth #=> "module_method" def inst_meth ; 'instance method' ; end end Keep in mind that meta is just another module. Its distinction as 'meta' is simply to indicate that it is working for a class to provide its "meta methods". Having a separate keyword I don't think is strictly neccessary, but it seems to help clarify the usage. Of course, to fully replace singleton classes the same can be done for objects. o = X.new meta o def mod_meth ; super + '!' ; end end o.mod_meth #=> "module method!" Now, the effect all this has on modules themselves is that they would no longer have a "class-level", or better that is to say their class-level and their instance-level are the same. In a sense is as if they always had 'extend self' implied. In so being they are simply one-fold encapsulations. module X def mod_meth ; 'module method' ; end mod_meth #=> "module_method" end >From another perspective, prototypical objects: module X def mod_meth ; 'module method' ; end end X.mod_method #=> "module method" >From this classes themselves become easier to understand --they are strictly two-fold entities with clearly separated meta and instance levels. The meta-module would easily be accessable -- even inheritable: class Y include X.meta_module end Fundamentally what changes here is the modules no longer would have the "scary door" behind them --Module would no longer be the superclass of Class. Rather Class and Module stand on thier own. What was: .------------------. | | Object---->(Object) | ^ ^ ^ ^ | | | | | | | | .-----' '---------. | | | | | | | '-----------+ | | | | | | | .------' | Module--->(Module)-----> "Scary Door" | | ^ ^ | | | | | | | | | | | | | Class---->(Class)-----> "Scary Door" | | ^ | | | | | | | '----------------' | | OtherClass-->(OtherClass)----------------------> "Scary Door" Becomes .------------. .--------. v | v | Object---->(ObjectModule)------' ^ ^ ^ ^ ^ | | | | | | | | | | .----------------' | | | | | | | | '----------------. | .-------. | | | | | v | | '-----------------. | Module------' | | | | .-------. | | | | v | | | Class---->(ClassModule)------' | | | | | | | | .-------. | | v | OtherClass-->(OtherModule)-----' Which (assuming I haven't overlooked something vital) looks a whole lot more inviting. T.