MG Mud User | 88f1247 | 2016-06-24 23:31:02 +0200 | [diff] [blame^] | 1 | LPC Basics |
| 2 | Written by Descartes of Borg |
| 3 | first edition: 23 april 1993 |
| 4 | second edition: 01 july 1993 |
| 5 | |
| 6 | CHAPTER 5: The Basics of Inheritance |
| 7 | |
| 8 | 5.1 Review |
| 9 | You should now understand the basic workings of functions. You should be |
| 10 | able to declare and call one. In addition, you should be able to recognize |
| 11 | function definitions, although, if this is your first experience with LPC, |
| 12 | it is unlikely that you will as yet be able to define your own functions. |
| 13 | There functions form the basic building blocks of LPC objects. Code |
| 14 | in them is executed when another function makes a call to them. In making |
| 15 | a call, input is passed from the calling function into the execution of |
| 16 | the called one. The called function then executes and returns a value |
| 17 | of a certain data type to the calling function. Functions which return |
| 18 | no value are of type void. |
| 19 | |
| 20 | After examining your workroom code, it might look something like this |
| 21 | (depending on the mudlib): |
| 22 | |
| 23 | ----- |
| 24 | inherit "/std/room"; |
| 25 | |
| 26 | void 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 | |
| 36 | If you understand the entire textbook to this point, you should recognize |
| 37 | of 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 | |
| 44 | This chapter will seek to answer the questions that should be in your head |
| 45 | at 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 | |
| 51 | 5.2 Object oriented programming |
| 52 | Inheritance is one of the properties which define true object oriented |
| 53 | programming (OOP). It allows you to create generic code which can be used |
| 54 | in many different ways by many different programs. What a mudlib does is |
| 55 | create these generalized files (objects) which you use to make very specific |
| 56 | objects. |
| 57 | |
| 58 | If you had to write the code necessary for you to define the workroom above, |
| 59 | you would have to write about 1000 lines of code to get all the functionality |
| 60 | of the room above. Clearly that is a waste of disk space. In addition, |
| 61 | such code does not interact well with players and other rooms since every |
| 62 | creator is making up his or her own functions to perform the functionality |
| 63 | of a room. Thus, what you might use to write out the room's long description, |
| 64 | query_long(), another wizard might be calling long(). This is the primary |
| 65 | reason mudlibs are not compatible, since they use different protocols for |
| 66 | object interaction. |
| 67 | |
| 68 | OOP overcomes these problems. In the above workroom, you inherit the |
| 69 | functions already defined in a file called "/std/room.c". It has all |
| 70 | the functions which are commonly needed by all rooms defined in it. When |
| 71 | you get to make a specific room, you are taking the general functionality |
| 72 | of that room file and making a unique room by adding your own function, |
| 73 | create(). |
| 74 | |
| 75 | 5.3 How inheritance works |
| 76 | As you might have guessed by now, the line: |
| 77 | |
| 78 | ----- |
| 79 | inherit "/std/room"; |
| 80 | ----- |
| 81 | |
| 82 | has you inherit the functionality of the room "/std/room.c". By inheriting |
| 83 | the functionality, it means that you can use the functions which have |
| 84 | been 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 |
| 86 | set_exits() declared and defined. In your function create(), you are |
| 87 | making calls to those functions in order to set values you want your |
| 88 | room to start with. These values make your room different from others, yet |
| 89 | able to interact well with other objects in memory. |
| 90 | |
| 91 | In actual practice, each mudlib is different, and thus requires you to use |
| 92 | a different set of standard functions, often to do the same thing. It is |
| 93 | therefore beyond the scope of this textbook even to describe what |
| 94 | functions exist and what they do. If your mudlib is well documented, |
| 95 | however, then (probably in /doc/build) you will have tutorials on how |
| 96 | to use the inheritable files to create such objects. These tutorials |
| 97 | should tell you what functions exist, what input they take, the data |
| 98 | type of their output, and what they do. |
| 99 | |
| 100 | 5.4 Chapter summary |
| 101 | This is far from a complete explanation of the complex subject of inheritance. |
| 102 | The idea here is for you to be able to understand how to use inheritance in |
| 103 | creating your objects. A full discussion will follow in a later textbook. |
| 104 | Right 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 | ----- |
| 117 | inherit "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 | |
| 123 | Note: |
| 124 | You may see the syntax ::create() or ::init() or ::reset() in places. |
| 125 | You do not need fully to understand at this point the full nuances of this, |
| 126 | but you should have a clue as to what it is. The "::" operator is a way |
| 127 | to call a function specifically in an inherited object (called the scope |
| 128 | resolution operator). For instance, most muds' room.c has a function |
| 129 | called create(). When you inherit room.c and configure it, you are doing |
| 130 | what is called overriding the create() function in room.c. This means |
| 131 | that whenever ANYTHING calls create(), it will call *your* version and not |
| 132 | the one in room.c. However, there may be important stuff in the room.c |
| 133 | version of create(). The :: operator allows you to call the create() in |
| 134 | room.c instead of your create(). |
| 135 | An example: |
| 136 | |
| 137 | ----- |
| 138 | #1 |
| 139 | |
| 140 | inherit "/std/room"; |
| 141 | |
| 142 | void create() { create(); } |
| 143 | ----- |
| 144 | |
| 145 | ----- |
| 146 | #2 |
| 147 | |
| 148 | inherit "/std/room"; |
| 149 | |
| 150 | void create() { ::create(); } |
| 151 | ----- |
| 152 | |
| 153 | Example 1 is a horror. When loaded, the driver calls create(), and then |
| 154 | create() calls create(), which calls create(), which calls create()... |
| 155 | In other words, all create() does is keep calling itself until the driver |
| 156 | detects a too deep recursion and exits. |
| 157 | |
| 158 | Example 2 is basically just a waste of RAM, as it is no different from room.c |
| 159 | functionally. With it, the driver calls its create(), which in turn calls |
| 160 | ::create(), the create() in room.c. Otherwise it is functionally |
| 161 | exactly the same as room.c. |