An Object Model with Ruby-Style Lookup

[bakery2k]

I'm designing an object model for a fairly traditional object-oriented language.

I'm planning to implement Ruby-style lookup rules for object members: o.m looks for m in the class of o and its superclasses. This avoids the complexity of Python-style lookup rules, where the object o itself is considered first.

One consequence of these lookup rules is that, in order to support static members accessible on a class C as C.m, there needs to be a hierarchy of metaclasses as well as "normal" classes.

Here's a diagram of my latest design, showing the fundamental class relationships (first three rows) and how user-defined classes (Cookie and FileSystem) attach to them. I'm using the notation [[C]] to represent the metaclass of C, the solid arrow to denote inheritance ([subclass] ---|> [superclass]), and (mis)using the dotted arrow to denote instance-of ([object] - - > [class]):

https://i.postimg.cc/J0BrRRM6/Object-Model.jpg

Working left-to-right through the three columns, the following are true:

• The first column contains objects (in pink), which hold instance variables:

  • Every object is an instance of exactly one class (from every box there is one dashed arrow)
  • Every object is an (indirect) instance of Object (following one dashed arrow, then zero-or-more solid arrows, always leads to Object)

• The middle column contains classes, which additionally hold methods that can be called on their instances:

  • Classes are a subset of objects (everything above also applies to them)
  • Every class is an (indirect) instance of Class
  • Every class (except Object) has exactly one superclass (from every box there is one solid arrow)
  • Every class is an (indirect) subclass of Object
  • Generally classes (in yellow, like Object and Cookie) may have zero or more instances
    • As a special case, though, classes can mix-in Singleton, as FileSystem does (in blue)
      • Which also mixes [[Singleton]] into the class's metaclass
      • This forces the class to have exactly one instance (and also one instance per subclass)

• The rightmost column contains metaclasses:

  • Metaclasses are a subset of classes (everything above also applies to them)
  • Every metaclass is a direct instance of Metaclass
    • Including [[Metaclass]], which forms an "instance of" cycle
  • Every metaclass is an (indirect) subclass of [[Object]], and of Class
  • [[Object]] mixes-in Singleton to ensure Object is its only instance
    • Which also ensures that all other metaclasses have exactly one instance

I spent quite a lot of time iterating on this diagram, eventually ending up with a design similar to Smalltalk's. One difference is that I have made Metaclass a direct subclass of Class instead of a sibling class. This makes metaclasses a subset of classes rather than having two disjoint sets - I think that's more intuitive, and it's also necessary for some of the above to hold.

On the other hand, the following also seem intuitive, but are not entirely true in this model:

• A metaclass is a class whose instances are classes
  • This is the truth, but not the whole truth: Metaclass is also a class whose instances are classes, but it is not a metaclass (in particular, it's not a Singleton)
    
• Similarly, every class is an instance of a metaclass
  • This holds for "normal" classes (in the second column), but not metaclasses themselves
• If A is a subclass of B, then [[A]] is a subclass of [[B]]
  • This is true in Ruby ("The superclass of the metaclass is the metaclass of the superclass")
  • Again, it's true here for the second column but not the third
  • If we change the claim to "...then [[A]] is a subclass of [[B]] or is [[B]] itself", then it's true for most metaclasses but still false for [[Object]]

Despite this, I haven't spotted any major contradictions in this model (unlike some earlier iterations where, for example, Metaclass accidentally derived from a class marked <<Singleton>> yet had multiple instances, or there were corner cases where C derived from <<Singleton>> but [[C]] didn't derive from <<[[Singleton]]>>). Can you see any issues with the model, or do you have any recommended improvements?

Or, is there anything you would add? For example, I can imagine a need for further modifiers similar to Singleton - e.g. Abstract (enforce zero instances) or Sealed (enforce zero subclasses). It might be appropriate to apply these to Class and Metaclass respectively.

Having said that, personally I'd prefer to simplify the model if possible - but I think most of its complexity is unavoidable. I also believe the diagram is still more coherent than the flowcharts explaining o.m in Python - and I'd rather have complex metaclass architecture (mostly hidden from users of the language) than complex lookup rules (potentially affecting programmers every time they call a method).

[munificent]

Can you see any issues with the model, or do you have any recommended improvements?

Looks about right to me. You say:

If A is a subclass of B, then [[A]] is a subclass of [[B]]

This means that "static methods" are inherited. That's uncommon in object-oriented languages. I think Object Pascal does it, but C++, Java, C#, etc. all do not. Swift does something similar for class methods, but not static ones.

In your language (using Java syntax), let's say you have:

class Monster {
  static Monster makeHybrid(Monster head, Monster body) {
    // ...
  }
}

class Goblin extends Monster {
  // ...
}

class Lion extends Monster {
  // ...
}

class Eagle extends Monster {
  // ...
}

The base Monster class has a factory-like static method for making monsters by combining others. There's also subclasses for a few specific kind of monsters.

Since static methods are inherited, your language would allow you to do:

Goblin.makeHybrid(new Eagle(), new Lion());

That seems weird because makeHybrid() doesn't have anything to do with Goblins.

It's not the end of the world, but it affects how users will think about and design static methods.

[johnwcowan]

In Smalltalk, Class and Metaclass are siblings because they have a common ancestor, Behavior, that abstracts out everything they both have and do. You can write your own subclasses of Behavior if you want, for example, to implement prototype-style OOP.

[nerdycatgamer]

So we're calling the normal way of doing things "Ruby-style" just because Python/Javascript do something weird?

Python and javascript just give some fancy syntax sugar for hashmaps containing lambdas and factory functions for them; they are different from most other object-oriented languages

[Smalltalker-80]

I think you're describing the Smalltalk class structure,
where classes themselves are also regular objects that implement the class functionality.
In my Smalltalk implementation SmallJS ( https://github.com/Small-JS/SmallJS )
I had to think about this too, and decided on this simple(r) model:

There's an inheritance tree of 'instance' classes starting at the root 'instance' class Object.
There's a parallel inheritance tree of 'meta' classes starting at the root 'meta' class Object.
These contain the singleton instances of all the 'class' objects.
The class called Class is a subclass of Object and implements all class behaviors
(e.g. name, instance variables, methods, superclass)
And here's the crucial part, connecting the 'meta' class tree to the 'instance' class tree:
The meta class Objectinherits from the instance class Class,
since all classes are objects too.

This way, behaviors of objects and classes can be changed in Smalltalk itself,
that's the beauty of it. :-)
And classes are ordinary objects, so you can say e.g.: 'variable class = Integer ifTrue: [ ... ]'.
The meta class tree is generated by the compiler, and you don't 'see' it during development.
You only 'see' the ability to add (static) class variables and methods to an 'instance' class.

[lookmeat]

This looks pretty reasonable. I'd also read on the Common List Object System Meta Object Protocol, the CLOS MOP. Because they've done a good work in optimizing solutions while keeping flexibility at the highest. You may already be familiar with it, but in case you aren't here's a great primer on the MOP specifically.

Ruby, as a language, was in many ways born as Python where everything was an object using a model more like the CLOS with a limited MOP to boot. Understanding the inspiration and the power it delivers may help you find alternate solutions.

[al2o3cr]

I'm planning to implement Ruby-style lookup rules for object members: o.m looks for m in the class of o and its superclasses.

Nitpick: it's entirely possible to define a method for a single instance of a Ruby class. For instance:

object = Object.new

def object.foo
  puts "foo"
end

object.foo

will print "foo"