This post originated from an RSS feed registered with Ruby Buzz
by Trans Onoma.
Original Post: Shutting the Scary Door
Feed Title: TRANSONOMA
Feed URL: http://feeds.feedburner.com/transonoma
Feed Description: A Light Green Agile Programming and SciTech Blog
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.
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 easily do everything we do now with classes alone. So, if there's a good use, why not make modules something truly unique from classes? As it so happens there is: 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 still one important minor distinction I'm going to go ahead and make upfront. Modules that serve in place of singleton classes do not have names. Instead, they are referred to via the class or object they "meta" for, so to speak. B/c of this I'll introduce the keyword 'meta', instead of 'module', for this specific use of replacing singleton classes in order to spare confusion and make the syntax more intuitive.
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 ot indicate that it is working for a class to provide its "meta methods". 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 in general is that they would no longer have a "class-level", or better their class-level === instance-level. In effect they always have '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"
Likewise classes themselves become easier to understand --they are strictly two-fold entities with clearly separated meta and instance levels. They no longer have the "scary door" behind them.
Fundamentally what changes here is that a module is no longer the superclass of a class. Rather a class stands on it's own. What was:
Previous Topic
