Geas Home | Play the Game

2.2.2 Inheriting object classes

Assume that you want to code an item like a door, for example. Doing that means that you have to create functionality that allows the opening and closing of a passage between two rooms. Perhaps you want to be able to lock and unlock the door, and perhaps you want the door to be transparent. All of this must be taken care of in your code. Furthermore, you have to copy the same code and make small variations in description and use every time you want to make a new door.

After a while you'll get rather tired of this, particularly as you'll find that other wizards has created doors of their own that work almost - but not quite - the same way your does, rendering nifty objects and features useless anywhere but in your domain.

The object oriented way of thinking is that instead of doing things over and over you create a basic door object that can do all the things you want any door to be able to do. Then you just inherit this generic door into a specialized door object where you configure exactly what it should be able to do from the list of available options in the parent door.

It is even possible to inherit several different objects where you can combine the functionality of several objects into one. However, be aware that if the objects you inherit define functions with the same names, they will indeed clash. Just be aware of what you are doing and why, and you won't have any problems.

The syntax for inheriting objects is very simple. In the top of the file you write this:

inherit "<file path>"; e.g. inherit "/std/door"; inherit "/std/room.c";

NB! This is NOT a preprocessor command, it is a statement, so it does NOT have a # in front of it, and it is ended with a ;. As you see you may specify that it's a c-file if you wish, but that's not necessary.

The child will inherit all functions and all variables that are declared in such a way as to permit inheriting. If you have a function with the same name as a function in the parent, your function will mask the parent one. When the function is called by an external call, your function will be executed. Internal calls in the parent will still go to the parent function. Often you need to call the parent function anyway from the child, you do that by adding :: to the internal function call.

void my_func() { /* * This function exists in the parent, and I need to * call it from here. */ ::my_func(); // Call my_func() in the parent. }

It is not possible to call a masked function in the parent by an external call, it is only available from within the object itself.

You can even add up more than one :: instruction on top of another to reach higher levels. Each :: only means 'back up one inheritance step, and look for the function there. If it's not there, look further up'. So, ::::::func() simply means 'back up three inheritance steps and look for func() there, if not found, look even further up until you find it'.

If you have managed to confuse matters by having a function with the same name as an efun, the compiler needs a bit of help in knowing which function you actually mean. Now, it isn't exactly the brightest thing you can do to put yourself in this situation, but you will even find examples of it in the mudlib (in /std/player/savevars_sec.c to be specific, and I even *cough* seem to remember that it was I who wrote that part once upon a time), so I guess even the sun has spots... Anyway, to solve the problem, simply precede any such efun call with the instruction efun::, and the compiler will know what you mean.

void deep_inventory(object ob) { write("Dumping inventory of object '" + file_name(ob) + "'"); dump_array(efun::deep_inventory(ob)); /* Call to real efun */ } int my_fun(string arg) { object ob; if (objectp((ob = find_object(arg)))) deep_inventory(ob); /* Call to local version above */ }