| 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(); |
| 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" }) ); |
| } |
| ----- |
| |
| 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 set_property(), set(), and set_exits(), 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 set_property(), set(), and set_exits() 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, |
| 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. |
| |
| 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, 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. |
| |
| 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. |