simul_efun |
Discworld creator help |
simul_efun |
Name
simul_efun - Simulated efunctions concept
Description
There is a mechanism to allow the mudlib to simulate efunctions. All simulated efuns must be defined in a special file (the name and location of which are to be specified in the config file).
When compiling an object and a function call (not a call_other()) is found that has not been defined in the object then the driver will search for that function in the list of simulated efuns. If the function is found in that list, then the driver sets up a call to that function (as defined in the simulated efun file).
Simulated efuns have many uses. One is that it is now possible to make major changes (and even removals) to the behavior of efuns without modifying the driver (by making a simul_efun having the same name as an efun). Suppose you wish to modify the behavior of the move_object() efun. You could do so by defining a simulated efun having the same name. The simulated efun could perform various restrictive checks and then call efun::move_object(). The efun:: prefix is necessary so that the driver will know you wish to call the move_object() efun and not recursively call the simul_efun within which the call to move_object() is contained. [Note that the valid_override() apply in the master object can be used to control which simul_efuns may be overridden via the efun:: prefix]. Simulated efuns are also useful for adding functions that many different objects may need to call but which aren't appropriate for inclusion in an inherited file.
Any function in the simulated efun file that is declared protected, will not be callable by functions outside the simulated efun file.
