[DGD] Inheritance create()

Michael McKiel crashnbrn71 at yahoo.ca
Mon Mar 15 23:08:50 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
> 
> 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.
> 
> Thanks 

I will note, the auto that is inherit'ing these lib's doesn't have a create,
nor do the objects that in the end inherit the auto.

I'm just bumping this cause it appears to of gotten lost in the other thread?
I just thought someone would know, why the kernel/api works(assigns a value
to its userd variable) so long as no other create() functions are in the
inheriting files, but fails when they do. And possibly why the create() {
::create(); } in the secure/api causes error.

I do have a workaround, don't put a create in the secure/api ;) but I really
dont get why its necessary.

Thanks again.


______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca
_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd



More information about the DGD mailing list