The Minimalist Object System and Your Lousy Axioms

The moral of this story comes first: Parsimony of axioms is not the sole virtue of language design.

Imagine you're designing PythonPerl 5. What's the minimum feature set you need to implement to provide an object system?

Objects have methods. Objects have attributes. Objects can have classes. (You can write a very workable object system where objects lack classes and only have methods, or messages, and no attributes, but humor me.) Thus you need a mechanism of attribute access, a mechanism of object creation, and a mechanism of method dispatch.

If you already have core language support for an abitrary data structure which associates names with values (a hash, a hashmap, a dict, a table, or whatever you call it), you can steal it to support attributes. It's very easy and tempting; after all, what is an attribute other than a named slot containing a value? (If it's good enough for C programmers, it's good enough for the rest of us.)

If you already have some mechanism for partitioning the world into separate namespaces, methods are almost as easy. You very likely also have functions, so a method can be a function in the appropriate namespace. That's also very easy.(This is better than what C programmers get, as they need a struct full of function pointers as well as the ability to hide that struct from people who shouldn't poke into it. Then again, C programmers are either unconcerned about encapsulation or very used to faking namespaces with prefixes and macros and the use of the static keyword (and, yes, I've written more than my share of pseudo-OO C)).

With those two pieces in place, the obvious question of instance creation and method dispatch almost resolves itself. Object creation means allocating the appropriate hash/map/dict/table and somehow associating it with the appropriate namespace. You can do this by blessing a particular syntactic construct as always obviously creating and associating:

someObj = SomeObj();

... and hiding the details of the hash/map/dict/table behind additional syntax, or you can embrace the minimalism of the need to add only two additional primitives and allow users to perform that association a bit more directly:

bless $hash_ref, 'Some::Class';

Your preference for or against syntax probably guides that decision.

There are other concerns, such as whether you allow inheritance. (You probably do, for two reasons. First, you're not writing a good object system anyway. Second, you know that many people like writing OO code because they believe it's primarily a design strategy to reuse code.) You also have to figure out a method dispatch strategy and how to represent parent and child relationships between classes.

If a class is just a namespace, why add syntax? You could use a variable or some other type of attribute of the namespace to identify a subclassing relationship.

Now go write some code (and not much), and you have a working object system built from a small set of core axioms that your language probably also has.

Isn't minimalism in language design great? (If you still believe you can answer "yes" to that question, see distributions containing "class" on the CPAN.