blob: 29d2a0c035ce3c849b4afe44713d91d54d674be3 [file] [log] [blame]
MG Mud User88f12472016-06-24 23:31:02 +02001 LPC Basics
2 Written by Descartes of Borg
3 first edition: 23 april 1993
4 second edition: 01 july 1993
5
6CHAPTER 5: The Basics of Inheritance
7
85.1 Review
9You should now understand the basic workings of functions. You should be
10able to declare and call one. In addition, you should be able to recognize
11function definitions, although, if this is your first experience with LPC,
12it is unlikely that you will as yet be able to define your own functions.
13There functions form the basic building blocks of LPC objects. Code
14in them is executed when another function makes a call to them. In making
15a call, input is passed from the calling function into the execution of
16the called one. The called function then executes and returns a value
17of a certain data type to the calling function. Functions which return
18no value are of type void.
19
20After examining your workroom code, it might look something like this
21(depending on the mudlib):
22
23-----
24inherit "/std/room";
25
26void create() {
27 ::create();
28 set_property("light", 2);
29 set_property("indoors", 1);
30 set("short", "Descartes' Workroom");
31 set("long", "This is where Descartes works.\nIt is a cube.\n");
32 set_exits( ({ "/d/standard/square" }), ({ "square" }) );
33}
34-----
35
36If you understand the entire textbook to this point, you should recognize
37of the code the following:
38 1) create() is the definition of a function (hey! he did not declare it)
39 2) It makes calls to set_property(), set(), and set_exits(), none
40 of which are declared or defined in the code.
41 3) There is a line at the top that is no variable or function declaration
42 nor is it a function definition!
43
44This chapter will seek to answer the questions that should be in your head
45at this point:
46 1) Why is there no declaration of create()?
47 2) Where are the functions set_property(), set(), and set_exits() declared
48 and defined?
49 3) What the hell is that line at the top of the file?
50
515.2 Object oriented programming
52Inheritance is one of the properties which define true object oriented
53programming (OOP). It allows you to create generic code which can be used
54in many different ways by many different programs. What a mudlib does is
55create these generalized files (objects) which you use to make very specific
56objects.
57
58If you had to write the code necessary for you to define the workroom above,
59you would have to write about 1000 lines of code to get all the functionality
60of the room above. Clearly that is a waste of disk space. In addition,
61such code does not interact well with players and other rooms since every
62creator is making up his or her own functions to perform the functionality
63of a room. Thus, what you might use to write out the room's long description,
64query_long(), another wizard might be calling long(). This is the primary
65reason mudlibs are not compatible, since they use different protocols for
66object interaction.
67
68OOP overcomes these problems. In the above workroom, you inherit the
69functions already defined in a file called "/std/room.c". It has all
70the functions which are commonly needed by all rooms defined in it. When
71you get to make a specific room, you are taking the general functionality
72of that room file and making a unique room by adding your own function,
73create().
74
755.3 How inheritance works
76As you might have guessed by now, the line:
77
78-----
79inherit "/std/room";
80-----
81
82has you inherit the functionality of the room "/std/room.c". By inheriting
83the functionality, it means that you can use the functions which have
84been declared and defined in the file "/std/room.c" In the Nightmare Mudlib,
85"/std/room.c" has, among other functions, set_property(), set(), and
86set_exits() declared and defined. In your function create(), you are
87making calls to those functions in order to set values you want your
88room to start with. These values make your room different from others, yet
89able to interact well with other objects in memory.
90
91In actual practice, each mudlib is different, and thus requires you to use
92a different set of standard functions, often to do the same thing. It is
93therefore beyond the scope of this textbook even to describe what
94functions exist and what they do. If your mudlib is well documented,
95however, then (probably in /doc/build) you will have tutorials on how
96to use the inheritable files to create such objects. These tutorials
97should tell you what functions exist, what input they take, the data
98type of their output, and what they do.
99
1005.4 Chapter summary
101This is far from a complete explanation of the complex subject of inheritance.
102The idea here is for you to be able to understand how to use inheritance in
103creating your objects. A full discussion will follow in a later textbook.
104Right now you should know the following:
105 1) Each mudlib has a library of generic objects with their own general
106 functions used by creators through inheritance to make coding objects
107 easier and to make interaction between objects smoother.
108 2) The functions in the inheritable files of a mudlib vary from mudlib
109 to mudlib. There should exist documentation on your mud on how to
110 use each inheritable file. If you are unaware what functions are
111 available, then there is simply no way for you to use them. Always
112 pay special attention to the data types of the input and the data
113 types of ay output.
114 3) You inherit the functionality of another object through the line:
115
116-----
117inherit "filename";
118-----
119
120 where filename is the name of the file of the object to be inherited.
121 This line goes at the beginning of your code.
122
123Note:
124You may see the syntax ::create() or ::init() or ::reset() in places.
125You do not need fully to understand at this point the full nuances of this,
126but you should have a clue as to what it is. The "::" operator is a way
127to call a function specifically in an inherited object (called the scope
128resolution operator). For instance, most muds' room.c has a function
129called create(). When you inherit room.c and configure it, you are doing
130what is called overriding the create() function in room.c. This means
131that whenever ANYTHING calls create(), it will call *your* version and not
132the one in room.c. However, there may be important stuff in the room.c
133version of create(). The :: operator allows you to call the create() in
134room.c instead of your create().
135An example:
136
137-----
138#1
139
140inherit "/std/room";
141
142void create() { create(); }
143-----
144
145-----
146#2
147
148inherit "/std/room";
149
150void create() { ::create(); }
151-----
152
153Example 1 is a horror. When loaded, the driver calls create(), and then
154create() calls create(), which calls create(), which calls create()...
155In other words, all create() does is keep calling itself until the driver
156detects a too deep recursion and exits.
157
158Example 2 is basically just a waste of RAM, as it is no different from room.c
159functionally. With it, the driver calls its create(), which in turn calls
160::create(), the create() in room.c. Otherwise it is functionally
161exactly the same as room.c.