About:

If you have started learning ruby recently, you might have got baffled by the facts that,

• The class Class is a child of the class Module
• Whereas the Module is of type Class.

And, if you don’t know how to wrap your head around this paradox, you’re not alone. At our TechConative Study Group, we spent some time as well, and we arrived at a reasonable Mental Model on how this could be possible.

The below understanding would set the perspective and get a Mental Model of it.

Note: The keywords in code block represents ruby code. Hence, if you see Class that represents the actual Class in ruby. Whereas class means any class.

Classes are Object:

Contrary to the intuitive thought (for folks from Java, C#, etc.) to think Classes as fixed blue-prints, Classes in Ruby are actually objects of the class Class.

Still, How come Class.class is Class. How can a class be created from itself? How can we have something which is created with a blueprint of its own definition?

How come Module.class is Class when Class.superclass is Module? How can we have something be created with a blueprint of something that is yet to be created extending it?

All Objects(hence classes) as Map(/Dict/Hash):

The problem is, if we think classes and objects in the below sequence, Define a blueprint(representing the attributes, methods and superclass) . Define entities(object) following the blueprint.

Instead, what if we have a Class as Maps(/Dict/Hash) and the blueprints (representing the attributes, methods and superclass) are actually set after the creation? i.e.,

• If you want to set the type of object, you would set the key in the map that represents the type of the object.
• If you want to call a method in the object, you would lookup for the “type”, thus getting another Map representing the class, then lookup for the method to be called and invoke it.
• If you want to define a superclass, you would set the attribute that represents a superclass in the object.
• If a method is not available in the Map of the respective class, you would look for the superclass key of the respective class and look for the methods there and do this recursively as needed.

With this model, you don’t have to have the “blueprint” first to create an object. You can create the object first and define the type later. I.e., Create an object for class Class and then set the type as Class.

From the ruby source:

On doing a quick check to validate the theory, had a look into the ruby source, which I assume is actually where the basic classes are defined.

Seems like,

• The classes are represented by a C struct (which can be used to mimic a Map).
• The Objects representing the classes are created first and then the classes for them are set.
• The superclass, methods to be called everything (seems to be) set in the struct associated with the class.

Though we haven't got too much into the implementation, this mental model solves the paradox!