[Main page] [Overview]     /lpc /BASIC /chapter4

---

LPC Basics
Written by Descartes of Borg
24 april 1993

CHAPTER 4
The Basics of Inheritance

At this point, you should understand what a function is. You should know
how to declare one and how to call one. In addition, you should be able
recognize a function definition, although, if this is your first experience
with LPC, you should not yet fully be able to define your own function.
You also should be clear that these functions are what constitute an LPC
object, and that they accept input in the form of variables of certain
data types, and that they also return output to where they were called.
Functions therefore themselves are of a certain data type. Functions which
return no value are type void.

So now you go examine your workroom code and see something like this:
-- cut here --
inherit "std/room";

void create() {
set_property("light", 2);
set_property("indoors", 1);
set("short", "Descartes' Workroom");
set("long", "This is Descartes' workroom.\nGo away.\n");
set_exits( ({ "d/standard/square" }), ({ "square" }) );
}
-- cut here --
If you understand everything I have explained to this point, you should
be thinking one of two things:
1) Hey where are all these functions create() calls being defined?
2) These functions are probably efuns
In addition, you probably are wondering what that line inherit "std/room"
is since it is clearly not a function declaration or definition.
Well these two thoughts are tied together in a very important way.
No, there are no efuns in this example workroom. Actually, what has happened
is you have already defined these functions through the line:
inherit "std/room";

Inheritance is a property of object oriented programming. Namely, it
allows you to create generic objects with very generalized functions
and use those generalized functions in more specific objects. A mudlib's
primary function is to be a library of generalized inheritable objects
that can allow creators to create specialized objects with little trouble.

If you had to write the code necessary for you to define a room each time
you wrote a room, you would end up with huge files of redundant code
thus wasting disk space and making coding unbearably tedious. It would
also make it harder for objects created by different creators to interact
properly.

The actual functions available to you as a creator vary from mudlib to
mudlib. The example above comes from the Nightmare mudlib. Another
example of a similar room from the Igor mudlib:
-- cut here --
inherit "room/room";

void reset(int arg) {
if(arg) return;
set_light(1);
set_short("Descartes' Workroom");
set_long("Descartes' boring workroom.\nGo away!\n");
dest_dir = ({ "room/church", "church" });
}
-- cut here --
So as you see, it is beyond the scope of this manual to tell you how you
should build your room or weapon or monster, etc. since I could not
possibly cover all possible mudlibs. The point however is that
whatever mudlib you are using in LPC, it has a standard library of
objects with generalized functions which allows you to create specific
objects by inheriting the mudlib objects then customizing them through
calls to the predefined functions and making your own functions.

If you are working on a mud with a decent mudlib, it will have a document
(perhaps in /doc/build) that explains all functions in the mudlib's
standard library objects. Before you start coding, you should take
the time to examine this document on your mud. For the purposes of
this manual, I will explain what the first workroom does.
On Nightmare, room.c itself inherits other even more generalized objects.
through this chain of inheritance, all of the functions used in the
workroom are defined. There is first:
set_property("light", 2); and set_property("indoors", 1);
Two separate calls to the same function, set_property().
set_property() is declared as follows:
void set_property(string str, mixed arg);
The set_property() function thus accepts two parameters as input and does
not return any value. What it does is process the two parameters, the
first onbe being a string which is the name of a property ("light" or
"indoors"), the second being a value to be added to the property in
question.

SUMMARY:
Although far from a complete explanation of the concept of inheritance,
this one will suffice for beginning LPC. What is important is that you
understand the following:
1) Each mudlib has a library of generic objects with their own general
functions which are used to make it easier for standardizing the way
in which mud objects interact and also make it easier for creators
to code objects by inheriting these generic objects so that the same
code need not be rewritten every time you create a new object.
2) The functions which make each mud's standard library objects vary wildly
from mud to mud. The creators of your mud's mudlib should have put together
documentation which details how each function in mudlib objects are declared
and what those objects do. If you do not know what functions are
available to you, then there simply is no way for you to make use of them.
Always pay special attention to what data types functions are expecting
as parameters, and also to what data type the function returns. You
may pass any data type to those expecting mixed as a data type, but
pay careful attention with those as to how they are supposed to behave
since, for example, a function looking for either a string or an int
might accept mixed as its parameter, check to see if the value is a string
or int, perform its function if it is one of those, or discard it
without error if it is something else. These will drive you mad, since
you are getting no errors but the function is doing nothing. That
is why mixed should be used only in special cases. But that is for a
later chapter.
3) You inherit the functionality of another object with the line
inherit "filename";
at the beginning of an object file.