From the NannyMUD documentation
2001-01-13
shadows - shadows - external overloading of functions
Shadows are used to re-route the calls to lfuns through another object. In a sense, the functions in the shadowed object are overloaded by those in the shadowing object - for external function calls (i.e. call_other, ->). The shadowee still has access to the original functions by internal calls. This can be used to modify the returned value and the sideeffects of a function without having to re-define it, especially for objects that are not under your own control (i.e. you didn't write their definition files). Consider the driver as the sun, with the rays of light being the calls to local functions, lfuns. The shadowing object can then be thought of as blocking the sunlight for the shadowee, and filtering it, deciding what rays should be let through, and what colour they should have. This means also that when designing an object, the coder has to consider how shadows can be used on and affect the behaviour of the object. It might be a good idea to block the possibility to shadow certain functions, or perhaps make the object impossible to shadow at all. This involves a judgement call, as denying shadows increases security but decreases flexibility. For most objects, flexibility is more important than tight security.
Lib files, for example the player object, can only be shadowed by objects residing in /local.
// This code makes a an object, with id "my_very_special_gem" // have a varying short description. start_shadow() { object gem; gem = present("my_very_special_gem", environment(this_player())); if (!gem) return; shadow(gem, 1); } // start_shadow short() { switch (random(4)) { case 0 : return "a red gem"; case 1 : return "a green gem"; case 2 : return "a white gem"; default : return "a blue gem"; } } // short
shadow in concepts/shadows shadow in efun/object_related/shadow
hooks in build/hooks