<h3>Chapter 5: The Basics of Inheritance</h3>
<p><strong>Review</strong></p>
<p>
You should now understand the basic workings of functions.
You should be able to declare and call one.
In addition, you should be able to recognize function definitions,
although, if this is your first experience with LPC, it is unlikely
that you will as yet be able to define your own functions. There
functions form the basic building blocks of LPC objects. Code
in them is executed when another function makes a call to them.
In making a call, input is passed from the calling function into
the execution of the called one. The called function then executes
and returns a value of a certain data type to the calling function.
Functions which return no value are of type void.
</p>
<p>
After examining your workroom code, it might look
something like this (depending on the mudlib):
<pre>
inherit "/std/room";
void create() {
::create();
set_property("light", 2 );
set_property("indoors", 1 );
set("short", "Descartes' Workroom");
set("long", "This is where Descartes works.\nIt is a cube.\n");
set_exits( ({ "/d/standard/square" }), ({ "square" }) );
}
</pre>
If you understand the entire textbook to this point,
you should recognize of the code the following:
<ol>
<li>create() is the definition of a function (hey! he did not declare it)
<li> It makes calls to set_property(), set(), and set_exits(),
none of which are declared or defined in the code.
<li>There is a line at the top that is no variable or function
declaration nor is it a function definition!
</ol>
This chapter will seek to answer the questions that
should be in your head at this point:
<ol>
<li>Why is there no declaration of create()?
<li>Where are the functions set_property(), set(), and set_exits() declared and defined?
<li>What the hell is that line at the top of the file?
</ol>
</p>
<hr size="1">
<p><strong>Object oriented programming</strong></p>
<p>
Inheritance is one of the properties which define
true object oriented programming (OOP). It allows you to create
generic code which can be used in many different ways by many
different programs. What a mudlib does is create these generalized
files (objects) which you use to make very specific objects.
</p>
<p>
If you had to write the code necessary for you to
define the workroom above, you would have to write about 1000
lines of code to get all the functionality of the room above.
Clearly that is a waste of disk space. In addition, such code
does not interact well with players and other rooms since every
creator is making up his or her own functions to
perform the functionality of a room. Thus, what you might use
to write out the room's long description, query_long(), another
wizard might be calling long(). This is the primary reason
mudlibs are not compatible, since they use different protocols
for object interaction.
</p>
<p>
OOP overcomes these problems. In the above workroom,
you inherit the functions already defined in a file called "/std/room.c".
It has all the functions which are commonly needed by all rooms
defined in it. When you get to make a specific
room, you are taking the general functionality of
that room file and making a unique room by adding your own function,
create().
</p>
<hr size="1">
<p><strong>How inheritance works</strong></p>
<p>
As you might have guessed by now, the line:
<pre>
inherit "/std/room";
</pre>
has you inherit the functionality of the room "/std/room.c".
By inheriting the functionality, it means
that you can use the functions which have been declared and defined
in the file "/std/room.c" In the Nightmare Mudlib, "/std/room.c"
has, among other functions, set_property(), set(), and
set_exits() declared and defined. In your function
create(), you are making calls to those functions in order to
set values you want your room to start with. These values make
your room different from others, yet able
to interact well with other objects in memory.
</p>
<p>
In actual practice, each mudlib is different, and
thus requires you to use a different set of standard functions,
often to do the same thing. It is therefore beyond the scope of
this textbook even to describe what functions
exist and what they do. If your mudlib is well documented, however,
then (probably in /doc/build) you will have tutorials on how to
use the inheritable files to create such objects. These tutorials
should tell you what functions exist, what input
they take, the data type of their output, and what they do.
</p>
<hr size="1">
<p><strong>Chapter Summary</strong></p>
<p>
This is far from a complete explanation of the complex
subject of inheritance. The idea here is for
you to be able to understand how to use inheritance in creating
your objects. A full discussion will follow in a later textbook.
Right now you should know the following:
<ol>
<li>Each mudlib has a library of generic objects with their own
general functions used by creators through inheritance to make
coding objects easier and to make interaction between objects
smoother.
<li>The functions in the inheritable files of a mudlib vary from
mudlib to mudlib. There should exist documentation on your mud
on how to use each inheritable file. If you are unaware what functions
are
<li>available, then there is simply no way for you to use them.
Always pay special attention to the data types of the input and
the data types of ay output.
<li>You inherit the functionality of another object through the line:
</ol>
<ol>
<li><code>inherit "filename";</code>
<li>where filename is the name of the file of the
object to be inherited. This line goes at
the beginning of your code.
</ol>
Note:
<blockquote>
You may see the syntax ::create() or ::init() or
::reset() in places. You do not need fully
to understand at this point the full nuances of this, but you
should have a clue as to what it is. The "::" operator
is a way to call a function specifically in an inherited object
(called the scope resolution operator). For instance, most muds'
room.c has a function called create(). When you inherit room.c
and configure it, you are doing what is called overriding the
create() function in room.c. This means that whenever ANYTHING
calls create(), it will call *your* version and not the one in
room.c. However, there may be important stuff in the room.c version
of create(). The :: operator allows you to call the create() in
room.c instead of your create().
</blockquote>
An example:
<pre>
#1
inherit "/std/room";
void create() { create(); }
</pre>
<pre>
#2
inherit "/std/room";
void create() { ::create(); }
</pre>
Example 1 is a horror. When loaded, the driver calls
create(), and then create() calls create(),
which calls create(), which calls create()... In other words,
all create() does is keep calling itself until the driver detects
a too deep recursion and exits.
</p>
<p>
Example 2 is basically just a waste of RAM, as it is no different from room.c
functionally. With it, the driver calls its create(), which in turn calls ::create(),
the create() in room.c. Otherwise it is functionally exactly the same as room.c.
</p>
