163 lines
7.0 KiB
Plaintext
163 lines
7.0 KiB
Plaintext
chapter 5 "The Basics of Inheritance"
|
|
LPC Basics
|
|
Written by Descartes of Borg
|
|
first edition: 23 april 1993
|
|
second edition: 01 july 1993
|
|
|
|
CHAPTER 5: The Basics of Inheritance
|
|
|
|
5.1 Review
|
|
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.
|
|
|
|
After examining your workroom code, it might look something like this
|
|
(depending on the mudlib):
|
|
|
|
-----
|
|
inherit "/std/room";
|
|
|
|
void create() {
|
|
::create();
|
|
SetProperty("light", 2);
|
|
SetProperty("indoors", 1);
|
|
set("short", "Descartes' Workroom");
|
|
set("long", "This is where Descartes works.\nIt is a cube.\n");
|
|
SetExits( ({ "/domains/standard/square" }), ({ "square" }) );
|
|
}
|
|
-----
|
|
|
|
If you understand the entire textbook to this point, you should recognize
|
|
of the code the following:
|
|
1) create() is the definition of a function (hey! he did not declare it)
|
|
2) It makes calls to SetProperty(), set(), and SetExits(), none
|
|
of which are declared or defined in the code.
|
|
3) There is a line at the top that is no variable or function declaration
|
|
nor is it a function definition!
|
|
|
|
This chapter will seek to answer the questions that should be in your head
|
|
at this point:
|
|
1) Why is there no declaration of create()?
|
|
2) Where are the functions SetProperty(), set(), and SetExits() declared
|
|
and defined?
|
|
3) What the hell is that line at the top of the file?
|
|
|
|
5.2 Object oriented programming
|
|
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.
|
|
|
|
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,
|
|
GetLong(), another wizard might be calling long(). This is the primary
|
|
reason mudlibs are not compatible, since they use different protocols for
|
|
object interaction.
|
|
|
|
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().
|
|
|
|
5.3 How inheritance works
|
|
As you might have guessed by now, the line:
|
|
|
|
-----
|
|
inherit "/std/room";
|
|
-----
|
|
|
|
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, SetProperty(), set(), and
|
|
SetExits() 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.
|
|
|
|
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.
|
|
|
|
5.4 Chapter summary
|
|
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:
|
|
1) 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.
|
|
2) 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
|
|
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.
|
|
3) You inherit the functionality of another object through the line:
|
|
|
|
-----
|
|
inherit "filename";
|
|
-----
|
|
|
|
where filename is the name of the file of the object to be inherited.
|
|
This line goes at the beginning of your code.
|
|
|
|
Note:
|
|
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().
|
|
An example:
|
|
|
|
-----
|
|
#1
|
|
|
|
inherit "/std/room";
|
|
|
|
void create() { create(); }
|
|
-----
|
|
|
|
-----
|
|
#2
|
|
|
|
inherit "/std/room";
|
|
|
|
void create() { ::create(); }
|
|
-----
|
|
|
|
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.
|
|
|
|
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.
|