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

[Felix A. Croes]

"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