[DGD]clones, master objects, inheritable, etc...

[Kevin N. Carpenter]

Thanks Felix.

Static functions are exactly what I need - this will allow me to
remove some security code.

My use of re-entrant and re-usable was in terms of the code
associated with the master object.  At least that's the way I think
of it, which helps me understand how clones work.  I hadn't taken
into consideration how you pull off the new variable trick.  Nice
feature by the way <grin>.  I don't see how you could do a continuous
mud without this.

Kevin C.

-----Original Message-----
From: dgd-admin at list.imaginary.com
[mailto:dgd-admin at list.imaginary.com]On Behalf Of Felix A. Croes
Sent: Thursday, March 23, 2000 9:33 AM
To: dgd at list.imaginary.com
Subject: Re: [DGD]clones, master objects, inheritable, etc...


"Kevin N. Carpenter" <kevinc at monrou.com> wrote:

> Wanted to do a sanity check of my understanding of some basics:
>
> Master objects contain re-entrant, re-usable code and their own variable
> space.

I do not understand what you mean with "re-entrant" and "re-usable" code
in this context.  My understanding of these terms is that the properties
depend on the code, not on the definition of the master object.


> Clones contain a variable space and point to the master object code,
> saving the mud that code space.  Since the code space is shared, when
> the master object is changed, all clones see that change.

An object recompile can directly affect more than code.  New variables
may be added, old ones removed, or the order of variables may be
changed.  All changes in the master object will immediately be reflected
in the clones.


> Inheritable objects are similar to master objects, except that when it is
> inherited, a copy of the inheritable object is included into the code
space
> of the master object inheriting it.  Thus, if a master inheritable is
> changed, all objects previously inheriting it must be recompiled to force
> the changed code to be included.

Not correct.  A full understanding of inherited objects includes the
notion of "issues".  An inherited object may exist in several issues,
only one of which exists as a normal object at a time; the other,
older issues have been destructed as objects, but are still inherited.
Old issues are not fully removed until all objects that inherit them
have been destructed or recompiled.  driver->remove_program() will
not be called for the issue until that time.

Code is not copied from an inherited object, but referenced.

It is easiest to keep track of issues by their object index, which will
be different for each issue.

If your mudlib does not allow different issues of an object to exist
simultaneously (from a user's point of view -- the mudlib designer
must always take them into account), then the notion of isues is
unimportant.


> Include files are just that, code included.  When changed, all master
> objects or inheritable that use the include file will need to be
recompiled.
>
> The driver code keeps track of some of this for you, calling
recompile(obj)
> if obj is out of date with respect to something it inherits.  This call
> only occurs when another object that inherits obj is compiled.
>
> "nomask" functions cannot be overridden by any code inheriting them.
>
> "atomic" functions will revert the state of the mud to its state prior
> to the function being executed if the function fails.

Keep in mind that the implementation of atomic functions is still
incomplete.  In particular, you cannot create or destruct objects
within atomic functions yet.  This is unfortunate, since the object
registry would greatly benefit from atomic functions to keep the
database consistent.


> "private" functions are local to an object and cannot be called via
> call_other(a,b) (or its syntactical equivalent: a->b).

Private functions can also not be called in inherited objects.

Private variables cannot be accessed by inheriting objects.


> "static" variables retain their last value between function calls to
> an object.

Replace "static" by "global".  A static variable will not be changed
by those abominable kfuns, save_object() and restore_object().

Static functions cannot be called with call_other() from a different
object.


> Am I missing any other function or variable types (ignoring int, string,
> etc.)?  Have I goofed any of the object types?

You didn't include "varargs".  Static, nomask, atomic and varargs are
properly called function or variable "classes", to distinguish them
from "types".

Regards,
Dworkin

List config page:  http://list.imaginary.com/mailman/listinfo/dgd


List config page:  http://list.imaginary.com/mailman/listinfo/dgd