[DGD] Inheritance create()

Felix A. Croes felix at dworkin.nl
Thu Mar 18 14:23:22 CET 2004


Michael McKiel <crashnbrn71 at yahoo.ca> wrote:

> I seem to have some confusion going on here (suprise suprise)
>
> I have a 2nd auto, which inherits:
>     /inherit/secure/api/user.c

Side note: it is best not to let the second-level auto object inherit
anything, in order to avoid polluting the inheritance tables (as the
second-level auto object is inherited by almost every object in the
mud).


> Which in turn inherits, 
>     /inherit/kernel/api/user.c
>
> Now I don't explicitly call the create in the kernel/api, like how its done
> in the user.c, and so long as my own secure/api/user.c doesn't have a
> create() function then all is well and things are fine. 
>
> Things go quite awry if I put a create() in the secure/api/user.c
> And then the variable userd in the kernel's api doesn't gets assigned.
>
> Even if I make my create in the secure/api like:
> private object userd;
>     create() {
>         ::create();
>         userd = find_object(USERD);
>     }
>
> Using the same variable, shouldn't cause issue, cause they are both private.
> So the question being, why is the create() in the kernel's api content and
> runs and assigns its own private object userd, but if I put a create() in a
> lib that inherit's it, things go bonkers heh.

I have only a vague idea of what your inheritance tree looks like, but
here are some ideas that may or may not apply:

 - make sure that the second-level auto object is/is not inherited by
   all of the right objects.
 - make sure that the inheritance tree looks the way you think it does;
   for example check that the ::create() function called is the right
   one.
 - the second-level auto object may be inherited multiple times by
   other objects, all of which may call ::create() in the objects they
   inherit; make sure that having create() called several times does
   not lead to problems.

Regards,
Dworkin
_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd



More information about the DGD mailing list