From the NannyMUD documentation

LAST CHANGE

2002-11-17

TOPIC

NAME
        strict_types - type control in LPC.


DESCRIPTION
	GLOBAL TYPE CHECKING
	
	The only global typechecking that is normally performed in
	LPC is when global variables are explicitly initialised when
	declared. This is performed when the object is loaded. There
	is normally no typecheck performed at runtime either. This is
	very convenient; all the work is deferred to the driver. When
	you declare variables and give the type, you are really
	writing documentation for the human reader. The driver can do
	without it.

	You can turn on the global typechecking at loadtime through
	the use of the compiler directive '#pragma strict_types'.
	Normally, the type information is discarded after the object
	has been loaded, but if you want the compiler to save it for
	inheriting objects, you can use the directive
	'#pragma save_types'. 

	When you turn on global typechecking, you will have to:
	+ declare functions with explicit types,
	+ declare all function arguments with explicit types,
	+ honour the number of function arguments, or declare the
	  function as 'varargs',
	+ functions must be declared before they are used,
	+ results from call_other() must be explicitly casted to the
	  type of the variable that will hold the result, unless the
	  value and the variable are integers.


	LOCAL TYPECHECKING

	You can turn on local typechecking by declaring your functions
	with explicit type. This forces you to declare the types of
	the arguments to the function. Local typechecking means that
	typechecking is applied to the body of the function.


	ADVANTAGES OF USING TYPECHECKING

	+ It makes debugging a bit easier, since the error messages
	  gets better.
	+ It forces you to know better what you are doing; this is why
	  the lib uses strict typechecking.
	+ It makes LPC look a bit more like some strongly typed
	  languages. This is, however, an illusion.


	DISADVANTAGES OF USING TYPECHECKING

	+ It makes your life more interesting by demanding attention
	  to code details that you could live without.
	+ It marks more things as errors.
	+ It forces you to write a lot of code that doesn't solve your
	  problem at hand.
	+ It makes the code grow, reducing clarity of expression. You
	  will at times be forced to write a function as 'varargs
	  mixed foo(mixed bar)' instead of 'foo(bar)', and you will
	  sooner or later write a cast like '(mixed *)', at which
	  point strict types appears less than useful.