OO By Attributes

Abstract

This describes a different way of handling objects rather than using classes. These ideas are probably not new.

Background

I like to write MUDs. Not the actual world-building parts, but the guts, the bits that allow others to write the world-building parts.

I have recently been enchanted with SQLAlchemy. I don't think I'll ever find a more ideal solution for long-term storage than SQLAlchemy. This is an ORM, which allows the programmer to map classes to SQL database tables.

While playing around with yet another idea of a MUD, I started with the basic objects:

• Account
• Room
• Exit
• Player
• Mob
• Item

The idea was that I'd add new classes as new behaviors and attributes were introduced. I'd like to do so dynamically, so that the MUD becomes its own environment with its own rules. Ideally, a MUD admin could go and create an entirely new rule that applies world-wide while the MUD is still running.

I toyed with inheritance in SQLAlchemy and relational tables, but I quickly discovered that this was a mess. Rather than try to get it actually working, I gave up on the concept altogether. I gave up on the idea of structured data, really. I poked at ZopeDB and other object-oriented databases, and I quickly found that these were married to classes, which I felt wasn't appropriate.

The idea =

The idea came to me that you can extend items by adding attributes and effects. The rules would apply to all attributes, and each attribute would have special clauses in the rules. In this way, you don't need inheritance for items.

Well, if items, such as weapons, armor, and food, need not be distinct classes, could I do the same for rooms, exits, and people? The answer was, of course! A room is special because it is a container (like a bag), and it has exits (unlike a bag.) A mob is special because he has intentions, skills, etc... Players are special because they are bound to accounts. But ultimately, everything is really an item, or rather, and object.

So the generic object formed in my head, having these properties:

1. An object can have any attribute.
2. The rules apply to all objects equally. The rules distinguish one object's behavior form another based solely on their attributes.

Storing an object as a set of attribute-value pairs is almost trivial in a relational database. Of course, the true power of the database is sort of wasted. (I've never felt like the strict typing was beneficial anyway.)

What is Stored in the DB

Every object is indexed by its unique ID, of course. This can be, for sanity's sake, a UUID.

To every object is a set of attribute-value pairs. The value can be any Python value. We can store these in JSON or Python Pickle's format. The attribute must be a valid identifier.

Drawing on Python's behavior, perhaps the attribute's value could be a snippet of code. This would allow us to store methods as attributes.

Various indexes may need to be built into the system to quickly find objects who have particular attributes.

Running the Code

The MUD becomes a simple rules engine. It simply applies the rules which are defined in terms of attributes.

What's Like This?

This sounds surprisingly similar to SmallTalk, a language I've never truly explored.

It also sounds a little like Common Lisp's object model.