by Richard Bartle
Last time, I described the advantage of using commands as objects (in an object-oriented programming sense) in a MUD. Actually, this conclusion isnt strictly true because functions are the true objects commands are just examples of functions (Ill explain how come when I get around to talking about parsers).
A property is a function of an object that returns the value of a single data item associated with that object. A very simple example might be a property that states player characters have a strength of 50. Rather than tie the code for this property to the PLAYER object (so
This simple example shows another occasion for which we can utilize inheritance in a broader sense than is usually possible in MUDs. Suppose that a vanilla newbie player character is created with a whole set of attributes STRENGTH, DEXTERITY, STAMINA etc.. If the default value for all of them is the same (say 50) then normally youd have to define each one separately
Since were always going to be using the .code() method for our objects, we can drop it from the syntax we know its always going to be there. Well replace it with a colon, to remind us. Thus, we could define
If we step back and look what weve done here, weve effectively divorced the inheritance hierarchy from the code. Although things like SWORD and STRENGTH are objects and classes in the hierarchy, they have no code attached its all been moved over to the OOP objects, namely functions. Although that makes some kind of weird sense (if functions dont have code, what in the world does?!) it nevertheless leaves the programmer with an uneasy sense of somehow being duped. We have classes, we have objects, we have inheritance, but its nothing to do with code. Code is attached to OOP objects that are functions, but they arent in a hierarchy and they dont inherit from each other.
Well, actually they are in a hierarchy, only its an implicit one defined by the elements of the explicit hierarchy that make up the functions parameters. They have inheritance, too, although in practice it turns out to be unnecessary. Ill demonstrate shortly.
First, though, to get away from tangling ourselves up with two separate notions of classes and objects, lets call things like SWORD, GOBLIN and STRENGTH atoms. We thus have an explicit hierarchy of atoms, where child atoms have an "is a kind of" relationship with their parents. This is the atom hierarchy. Atoms have no executable code associated with them.
Functions are described by ordered lists of atoms, and they do have are pieces of executable code associated with them (e.g. evaluable expressions such as 50 and 6+6). Im going to show you how, using the atom hierarchy, functions can form the OOP hierarchy well be using.
Consider the following set of function/code pairs:
The atom hierarchy that goes with this is:
Ive kept this as a simple tree, to make it easier to follow whats going on theres no reason it couldnt be a full hierarchy. ?? is the universal root.
Now, lets try some function calls and figure out what they evaluate to. Ill write these as
This exercise shows that the functions do have a partial ordering: