The Minimalist Object System and Your Lousy Axioms

| 4 Comments

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.

4 Comments

The TrackBack option from wordpress.com seems not to work with this site.

Your post seems to be somewhat related to my blog post and Stevan Little's response to a comment of brian d foy my post.

C.

you're not writing a good object system anyway

Are you suggesting that a good OO system might not include inheritence? Perhaps emphasizing role-based object composition?

A really good object system doesn't artificially promote inheritance over other mechanisms of subclassing, genericity, and code reuse. That's all.

Sorry, chromatic. The comment function does not support HTML tags for urls (and were ignored).

Here are the URL's:
http://nxadm.wordpress.com/2011/01/01/what-i-would-love-to-see-in-2011-for-perl/
http://blog.moose.perl.org/2011/01/the-moose-ecosystem.html

Claudio

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

affiliated with ModernPerl.net

Categories

Pages

About this Entry

This page contains a single entry by chromatic published on January 5, 2011 12:35 PM.

Minimalism was the previous entry in this blog.

Hip vs. Useful is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.


Sponsored by Blender Recipe Reviews and the Trendshare how to invest guide

Powered by the Perl programming language

what is programming?