[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