LPC (programming language)
From Wikipedia, the free encyclopedia
| Paradigm: | prototype-based |
|---|---|
| Designed by: | Lars Pensjö |
| Developer: | Lars Pensjö and others |
| Major implementations: | LPC |
| Influenced by: | C |
| Influenced: | Pike |
The LPC programming language is an object-oriented programming language derived from C and developed by Lars Pensjö to facilitate MUD building on LPMuds. It has been used not only for mud game creation, but also has evolved into the Pike programming language used for various internet servers, multimedia applications and system administration tasks. LPC stands for 'Lars Pensjö C'.
LPC syntax is very similar to that of the Java programming language, but people used to programming in Java will notice the following key differences:
- Referencing a member of an object is done via the -> operator instead of the . operator (ob->method() instead of ob.method()).
- LPC has no general support for threading and execution stacks are limited in duration before they "time out".
Contents |
[edit] Basic structure
Almost everything in LPC is an object. However, LPC has no concept of a class (MudOS has something called a class, but it is really a struct). Instead, LPC objects are clones of a master object. You can treat a master object as you would a class in other object-oriented languages, except you cannot specify attributes that belong only to the master object, i.e. class variables.
Each object has attributes and methods. The attributes define what the object is; the methods define what that object does. An object is uniquely defined by the name of the file in which it comes from plus a numeric identifier. Thus, the third clone of the object defined in the file /lib/weapon.c will be /lib/weapon#3. In a MUD game, common objects include rooms, weapons, armor, and NPCs. Most mudlibs define inheritable objects for such common things. In the LPMud 2.4.5 mudlib, for example, the parent object for all rooms is /lib/room.
[edit] A simple room in a Typical Mudlib
Because LPC is generally used to code MUDs, 'rooms' are often created as objects that store information describing a particular scene along with exits that point to other room objects. This is only common usage of LPC. Other uses that are not game related are possible.
The following example shows a very simple room that leverages methods defined in the mudlib object /lib/room. However, not all mudlibs define or determine rooms in the same way. The following is typical of a traditional room, but is not the only method of defining a room.
inherit "/lib/room";
void create() {
::create();
set_short("a simple room");
set_long("A simple room in a simple building.");
set_description("This is a simple room in a simple building. It is very nice.");
add_exit("north", "/realms/descartes/north_room");
}
The first line tells the object to inherit functionality from the /lib/room object. This example assumes the /lib/room object defines methods for ::create(), set_short(), set_long(), and add_exit().
This example contains a single method, create(). Most drivers call or can be set to call create() to allow an object to initialize itself with startup values. In this case, the example calls functions that set up the basic room attributes in the inherited /lib/room. The functions you call here are highly dependent on the mudlib you are using since the mudlib defines the actual room parent.
[edit] Data types
Most LPC drivers have the following data types:
- object
- int
- string
- array
- mapping
- float
- status
You can count on object, int, string, and array being available in most drivers.
- An object is any LPC object, including both masters and clones.
- An int is a 32-bit integer.
- A string is a variable length string. You do not need to do any form of memory management or bounds management. LPC handles that for you.
In most drivers, you define an array by type in the same way you define a Java array:
- object[]
- int[]
- string[]
- string[][]
Under MudOS, you can use the following:
- string array
- class
Under DGD, you cannot use the following data types:
- array
- status
- class
Most drivers support the mapping, float, and status data types.
- A mapping is a hash map of keys to values.
- A float is a floating point value.
- A status is a value that holds a 1 or a 0 and thus represents true or false. It is deprecated in MudOS.
Class is unique to MudOS and behaves like a C struct. It is not a class in any object-oriented sense of the word.
[edit] Passing values
Primitive LPC types (int, string, status) are passed by value. All other types are passed by reference in a thread of execution.
This feature can be powerful, but it can also lead to security holes. In most mud systems, the people building the world are generally less trusted than the staff running the game. If an object passes a mapping with sensitive values like access control information, an author of another object can modify that and thus increase their access rights. Mudlib developers and game admins should thus be careful when passing complex types to lower access objects.
[edit] See also
[edit] External links
- LPC Basics by George Reese on Apr 23rd, 1993
- NannyMUD LPC by Mats H. Carlberg in March in 1998
- LPC Tutorial by Ronny Wikh on Jul 8th, 2003
- LPUniversity Foundation - LPC community, standards, research, education, and more.
