Added public files
Roughly added all public files. Probably missed some, though.
diff --git a/doc/LPC/modifiers b/doc/LPC/modifiers
new file mode 100644
index 0000000..a30904e
--- /dev/null
+++ b/doc/LPC/modifiers
@@ -0,0 +1,182 @@
+CONCEPT
+ modifiers
+
+DESCRIPTION
+ A modifier changes the syntactic and/or semantic behaviour of
+ an object-global variable or a function in an object.
+ The existing modifiers are described below.
+ To use a modifier just prepend it to the declaration. If several
+ modifiers are to be used their order does not matter:
+
+ private int bar; // example for a variable
+ protected nomask int foo() { return 3; } // example for a function
+
+ For functions:
+ ~~~~~~~~~~~~~~
+ private -- such functions can only be called with an internal
+ call from within this file. Not even inheriting
+ objects can call these functions. You can nevertheless
+ build an lfun-closure with #' out of a private function
+ (but you cannot save and restore it).
+ protected -- such functions can be called from within the object,
+ or from inheriting objects; but in neither case
+ with call_other(). It is possible to create #' closures
+ or use symbol_function() from within the object.
+ Its use is preferred over the older "static".
+ static -- such functions can be called from within the object
+ in either way (internal call or with call_other()).
+ Inheriting objects can call such functions.
+ But it is not possible to call static functions from
+ other objects via call_other().
+ The use of 'static' in new code is not recommended.
+ Note that an add_action() is treated like a call
+ from within the object except the player who got the
+ add_action() was forced (thus it is a simple way to
+ secure an add_action() against forces, although this
+ method has the severe disadvantages of raising an error
+ at the force so better use the security system).
+ Also efuns like call_out() or input_to() can call
+ these functions if given as a string.
+ public -- this is the default type. Such functions can be called
+ from within the file as well as from inheriting objects
+ and other objects via call_other().
+ To declare a function public only results in the
+ impossibility to change the accessibility at the
+ inherit statement (see below). No error will occur,
+ only the type will not be modified by the inherit
+ statement.
+ nomask -- such functions cannot be overridden by inheriting
+ objects. If you have the fun foo() defined in your
+ object and inherit an object which also has declared
+ a function foo() and this nomask, you will get an
+ compile error if you try to load your object.
+ Furthermore a shadow will fail if it tries to shadow
+ a nomask declared function.
+ varargs -- this changes the syntax of the function in a way that
+ not all of the arguments in the declaration must be
+ given at the call. This is often very usefull if some
+ of the arguments shall be omitable (the omitted
+ arguments are set to 0 if the function is called with
+ fewer arguments than specified).
+ This is mainly within the object really necessary;
+ call_other()s usually (that is if they do not have a
+ certain pragma ('man pragma')) do not need the called
+ function to be declared varargs to omit any arguments,
+ but it is good style to use this modifier to document
+ the code by this.
+ deprecated - Whenever this function is called, a warning is issued.
+ Usually this is done at compile-time. Exceptions are
+ call_others and symbol_function() which warn at run-time.
+
+ For object-global variables:
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ private -- such variables can only be accessed from within the
+ same object. Not even inheriting objects can access
+ private variables.
+ It is a good style to declare all internal variables
+ private to prevent inheriting objects from accessing
+ the variables directly without using functions.
+ nosave -- such variables are neither stored with save_object()
+ nor restored with restore_object(). This can be very
+ useful if you want a room to use save_object() and
+ restore_object() to save your own defined variables
+ but not the hundreds of variables inherited from a
+ room-class (e.g. /complex/room). You then use the modifier
+ at the inherit statement (see below).
+ Note that nosave and private do not overlap in any
+ way. They are absolutely independant.
+ static -- the old name for 'nosave'. Its use is deprecated.
+ public -- declares the variable public. It cannot be declared
+ private or static by inheriting. No error will occur,
+ only the type will not be modified by the inherit
+ statement.
+ deprecated - Whenever this variable is used, a warning is issue.
+ Usually this is done at compile-time, but
+ symbol_variable() warns at run-time.
+
+ It is no good style to let inheriting objects have access to
+ internal variables so declare them as private and offer functions
+ to query and change the variables if possible.
+
+ It is also possible to redeclare all variables and/or functions
+ of an inherited object for the own object at the inheriting
+ statement:
+
+ private functions nosave variables inherit "complex/room";
+ public variables inherit "complex/room";
+ private functions inherit "complex/room";
+
+ To redeclare a function or a variable declared public in the
+ inherited object to be private or protected is not possible.
+
+ There also exists a modifier explicitly for the inherit statement:
+
+ virtual -- inherits the given object virtually. This only makes
+ sense in a complex inherit tree.
+ If an object is inherited normally (not virtually)
+ twice somewhere in the inherit tree the intern
+ variables exist twice. If inherited virtually they
+ exist only once.
+ Example:
+ A inherits B and C.
+ B inherits D.
+ C inherits D.
+ If the inheritance of D is virtual in B and C
+ D's variables exist only once in A. If A changes
+ D's variables via functions of B this also changes
+ the variables of D as known by C.
+
+ virtual: non-virtual:
+ A A
+ / \ / \
+ B C B C
+ \ / | |
+ D D D
+
+
+ To simplify the adoption of existing code, LPC allows to specify
+ a default visibility for functions and variables, using a syntax
+ similar to the inherit syntax:
+
+ default private;
+
+ All variables and functions are by default private.
+
+ default private variables public functions;
+
+ All variables are by default private, but functions are public.
+
+ Only the modifiers 'private', 'public' and 'protected' (and 'static'
+ for functions only) are allowed here.
+
+ The default visibility thus set affects only variables/functions with
+ no explicite visibility:
+
+ default private;
+
+ int private_var;
+ public int public_var;
+
+ The definition is valid from the point of the 'default' statement
+ until the end of the file, or until the next 'default' statement:
+
+ default private;
+
+ int private_var;
+
+ default public;
+
+ int public_var;
+
+ Note that this default visibility does not affect inherits.
+
+
+HISTORY
+ The modifier 'static' for variables was renamed to 'nosave'
+ with LDMud 3.2.8. 'static' is still recognized as an alias.
+
+ The default visibility was added in LDMud 3.2.9 as experimental
+ feature.
+
+SEE ALSO
+ closures(LPC), inheritance(LPC), functions(LPC), types(LPC)