Man modifiers - Revision history

Laine at 17:44, 11 June 2007

Laine — Mon, 11 Jun 2007 17:44:28 GMT

←Older revision		Revision as of 17:44, 11 June 2007
Line 170:		Line 170:


-	==See Also==	+
-	[[man closures\|closures(LPC)]], [[man inheritance\|inheritance(LPC)]], [[man functions\|functions(LPC)]], [[man types\|types(LPC)]]	+

	==History==		==History==

Laine at 17:44, 11 June 2007

Laine — Mon, 11 Jun 2007 17:44:07 GMT

←Older revision		Revision as of 17:44, 11 June 2007
Line 168:		Line 168:
	Note that this default visibility does not affect inherits.		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==		==See Also==

Laine: /* Description */

Laine — Mon, 11 Jun 2007 17:43:07 GMT

Description

←Older revision		Revision as of 17:43, 11 June 2007
Line 110:		Line 110:

	*virtual -- inherits the given object virtually. This only makes		*virtual -- inherits the given object virtually. This only makes
-	sense in a complex inherit tree.	+	sense in a complex inherit tree.
-	If an object is inherited normally (not virtually)	+	If an object is inherited normally (not virtually)
-	twice somewhere in the inherit tree the intern	+	twice somewhere in the inherit tree the intern
-	variables exist twice. If inherited virtually they	+	variables exist twice. If inherited virtually they
-	exist only once.	+	exist only once.
-	Example:	+
		+	Example:
	A inherits B and C.		A inherits B and C.
	B inherits D.		B inherits D.
Line 123:		Line 124:
	D's variables via functions of B this also changes		D's variables via functions of B this also changes
	the variables of D as known by C.		the variables of D as known by C.
-	<nowiki>	+
	virtual: non-virtual:		virtual: non-virtual:
	A A		A A
Line 131:		Line 132:
	D D D		D D D

-	</nowiki>	+

	To simplify the adoption of existing code, LPC allows to specify		To simplify the adoption of existing code, LPC allows to specify
Line 166:		Line 167:

	Note that this default visibility does not affect inherits.		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==
		+	[[man closures\|closures(LPC)]], [[man inheritance\|inheritance(LPC)]], [[man functions\|functions(LPC)]], [[man types\|types(LPC)]]

	==History==		==History==

Laine: /* Description */

Laine — Mon, 11 Jun 2007 17:39:24 GMT

Description

Laine at 17:35, 11 June 2007

Laine — Mon, 11 Jun 2007 17:35:15 GMT

New page

==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.
*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().
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.

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.
The driver may be compiled to not recognize this
keyword ('static' is then to be used). If 'nosave'
is available, the macro __LPC_NOSAVE__ is defined.
*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.

It is not 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.
<nowiki>
virtual: non-virtual:
A A
/ \ / \
B C B C
\ / | |
D D D

</nowiki>

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==

[[man closures|closures(LPC)]], [[man inheritance|inheritance(LPC)]], [[man functions|functions(LPC)]], [[man types|types(LPC)]]

←Older revision		Revision as of 17:39, 11 June 2007
Line 13:		Line 13:

	*private -- such functions can only be called with an internal		*private -- such functions can only be called with an internal
-	call from within this file. Not even inheriting	+	call from within this file. Not even inheriting
-	objects can call these functions. You can nevertheless	+	objects can call these functions. You can nevertheless
-	build an lfun-closure with #' out of a private function.	+	build an lfun-closure with #' out of a private function.
	*protected -- such functions can be called from within the object,		*protected -- such functions can be called from within the object,
-	or from inheriting objects; but in neither case	+	or from inheriting objects; but in neither case
-	with call_other(). It is possible to create #' closures	+	with call_other(). It is possible to create #' closures
-	or use symbol_function() from within the object.	+	or use symbol_function() from within the object.
-	Its use is preferred over the older "static".	+	Its use is preferred over the older "static".
		+
	*static -- such functions can be called from within the object		*static -- such functions can be called from within the object
-	in either way (internal call or with call_other()).	+	in either way (internal call or with call_other()).
-	Inheriting objects can call such functions.	+	Inheriting objects can call such functions.
-	But it is not possible to call static functions from	+	But it is not possible to call static functions from
-	other objects via call_other().	+	other objects via call_other().
-	Note that an add_action() is treated like a call	+	Note that an add_action() is treated like a call
-	from within the object except the player who got the	+	from within the object except the player who got the
-	add_action() was forced (thus it is a simple way to	+	add_action() was forced (thus it is a simple way to
-	secure an add_action() against forces, although this	+	secure an add_action() against forces, although this
-	method has the severe disadvantages of raising an error	+	method has the severe disadvantages of raising an error
-	at the force so better use the security system).	+	at the force so better use the security system).
-	Also efuns like call_out() or input_to() can call	+	Also efuns like call_out() or input_to() can call
-	these functions if given as a string.	+	these functions if given as a string.
		+
	*public -- this is the default type. Such functions can be called		*public -- this is the default type. Such functions can be called
-	from within the file as well as from inheriting objects	+	from within the file as well as from inheriting objects
-	and other objects via call_other().	+	and other objects via call_other(). To declare a function public only results in the
-	To declare a function public only results in the	+	impossibility to change the accessibility at the
-	impossibility to change the accessibility at the	+	inherit statement (see below). No error will occur,
-	inherit statement (see below). No error will occur,	+	only the type will not be modified by the inherit
-	only the type will not be modified by the inherit	+	statement.
-	statement.	+
	*nomask -- such functions cannot be overridden by inheriting		*nomask -- such functions cannot be overridden by inheriting
-	objects. If you have the fun foo() defined in your	+	objects. If you have the fun foo() defined in your
-	object and inherit an object which also has declared	+	object and inherit an object which also has declared
-	a function foo() and this nomask, you will get an	+	a function foo() and this nomask, you will get an
-	compile error if you try to load your object.	+	compile error if you try to load your object.
-	Furthermore a shadow will fail if it tries to shadow	+	Furthermore a shadow will fail if it tries to shadow
-	a nomask declared function.	+	a nomask declared function.
		+
	*varargs -- this changes the syntax of the function in a way that		*varargs -- this changes the syntax of the function in a way that
-	not all of the arguments in the declaration must be	+	not all of the arguments in the declaration must be
-	given at the call. This is often very usefull if some	+	given at the call. This is often very usefull if some
-	of the arguments shall be omitable (the omitted	+	of the arguments shall be omitable (the omitted
-	arguments are set to 0 if the function is called with	+	arguments are set to 0 if the function is called with
-	fewer arguments than specified).	+	fewer arguments than specified).
-	This is mainly within the object really necessary;	+	This is mainly within the object really necessary;
-	call_other()s usually (that is if they do not have a	+	call_other()s usually (that is if they do not have a
-	certain pragma ('man pragma')) do not need the called	+	certain pragma ('man pragma')) do not need the called
-	function to be declared varargs to omit any arguments,	+	function to be declared varargs to omit any arguments,
-	but it is good style to use this modifier to document	+	but it is good style to use this modifier to document
-	the code by this.	+	the code by this.

	For object-global variables:		For object-global variables:

	*private -- such variables can only be accessed from within the		*private -- such variables can only be accessed from within the
-	same object. Not even inheriting objects can access	+	same object. Not even inheriting objects can access
-	private variables.	+	private variables. It is a good style to declare all internal variables
-	It is a good style to declare all internal variables	+	private to prevent inheriting objects from accessing
-	private to prevent inheriting objects from accessing	+	the variables directly without using functions.
-	the variables directly without using functions.	+
	*nosave -- such variables are neither stored with save_object()		*nosave -- such variables are neither stored with save_object()
-	nor restored with restore_object(). This can be very	+	nor restored with restore_object(). This can be very
-	useful if you want a room to use save_object() and	+	useful if you want a room to use save_object() and
-	restore_object() to save your own defined variables	+	restore_object() to save your own defined variables
-	but not the hundreds of variables inherited from a	+	but not the hundreds of variables inherited from a
-	room-class (e.g. /complex/room). You then use the modifier	+	room-class (e.g. /complex/room). You then use the modifier
-	at the inherit statement (see below).	+	at the inherit statement (see below). Note that nosave and private do not overlap in any
-	Note that nosave and private do not overlap in any	+	way. They are absolutely independent.
-	way. They are absolutely independant.	+	The driver may be compiled to not recognize this
-	The driver may be compiled to not recognize this	+	keyword ('static' is then to be used). If 'nosave'
-	keyword ('static' is then to be used). If 'nosave'	+	is available, the macro __LPC_NOSAVE__ is defined.
-	is available, the macro __LPC_NOSAVE__ is defined.	+
	*static -- the old name for 'nosave'. Its use is deprecated.		*static -- the old name for 'nosave'. Its use is deprecated.
		+
	*public -- declares the variable public. It cannot be declared		*public -- declares the variable public. It cannot be declared
-	private or static by inheriting. No error will occur,	+	private or static by inheriting. No error will occur,
-	only the type will not be modified by the inherit	+	only the type will not be modified by the inherit
-	statement.	+	statement.

	It is not good style to let inheriting objects have access to		It is not good style to let inheriting objects have access to
Line 162:		Line 166:

	Note that this default visibility does not affect inherits.		Note that this default visibility does not affect inherits.
-

	==History==		==History==