Forum: Ruby Closing the Scary Door -- Differentiating Modules from Class

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
45196398e9685000d195ec626d477f0e?d=identicon&s=25 unknown (Guest)
on 2006-05-23 19:36
(Received via mailing list)
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
"<a href="http://rubygarden.org/ruby/ruby?TheScaryDoor">scary door</a>"
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.
This topic is locked and can not be replied to.