[DGD] Shadows issue

[Kamil N]

Well, I agree shadowing is not the best thing on earth, but I can't
really come with solution that makes them obsolete. As far as I
remember shadows had lots drawbacks (determining which object is going
to be the final one masking when more than one shadows is applied and
they all mask the same function, security issues etc), but in some
cases they were really useful.

So my question is more about good ways to avoid shadows, rather than
reproducing them in DGD environment. I can imagine alot of situations
when I may need to _temporarily_ change result or behaviour of some
function in (for example) player object. It goes for all things like
changing gender due to some curse, changing whole body as I mentioned
in earlier post, basically change anything that may require change due
to some game design (curses, guild membership, mounts, sitting at the
table etc.).

The only partial solution I can come up with is deciding which
functions can be changed (like query_gender, query_short_name etc) and
creating some kind of objects (we can even call them shadows) which
will be applied to player somehow (even through something like arrray:
object *shadows). Then the function that, by design, allows itself to
be shadowed searches this array to check if any of these objects
define the same function, calls it and returns its result instead of
returning its own value. This I guess would be some kind of "reverse"
shadow, because you can't just shadow everything (call_other approach)
- its up to every function if it will check the existance of possible
shadows (not shadow changing function behaviour no matter what), or
just execute its normal code. But there are problems like how to
decide which shadow has priority if there are more than one shadow
objects masking the same function name.

Other than that maybe just coding mudlib so it can deal with any kind
of situation, so if player sits it adds proper descriptions, if hes
mounted, it adds proper leave/arrive messages etc. But all this
requires basically everything to be designed at the start, and shadows
allowed to create things that noone ever thought about when creating
base mudlib, but they were still possible to achieve through
shadowing.

Also, any way to do this "body" exchange I described? Maybe instead of
just inheriting it, storing it in some "object body", and changing
object associated with it when its needed? But then I'll need to call
all the functions on body instead of actual player object, or find a
way to somehow delegate them to the body?

Regards,
KN

2009/7/17 Shentino <shentino at gmail.com>:
> This might be a bit of advanced gobbledegook, but I think this might work
> for shadowing:
>
> override call_other to check the shadow with a "function_object" check to
> see if the shadower defines an alternative version.
>
> If so, call it, otherwise, call the normal object.
>
> You might have trouble with variables though.
>
> Personally I found shadowing to be an obfuscatory mess when dealing with
> actual code from what little I learned of it.  So, YMMV.