[DGD] Shadows issue

[Carter Cheng]

>From my perspective shadows are not really required if you are designing a mudlib from the ground up. If you need to have player objects which change behavior in some fashion at runtime you can use composition and something akin to a state pattern similar to what Quix and Felix are both talking about. 

I think it is sometimes convenient to use a shadow like mechanism to decorate existing code where a given program has an extremely wide/large interface(in an existing lib) and you can get this behavior by overriding call_other to some extent though creating nomask functions might require some compromise(since you cannot annotate directly functions as nomask). I.e. you might need to have a pair of simple set/get simulated kfuns in the auto object which report back when you cannot override a given function and stick data in there manually.