[DGD]recompile

[Felix A. Croes]

Stephen Schmidt <schmidsj at union.edu> wrote:

> There is a function called recompile() in driver.c, which
> seems to be called by the game driver itself. In early
> mudlibs it does nothing. In the current kernel it seems
> to destruct the object and all objects which the object
> inherits it.
>
> 1) When is this called, and why do we need to go into the
> driver object to do it? I imagine that what happens is
> that the driver gets the request to compile an existing
> object, preserves its state, then invokes recompile()
> to see if the mudlib wants anything done, then compiles
> the object, then restores the state. More or less right?

The recompile() function is called in the following case:

Object A is inherited by B.  Object A is then destructed, so
B now inherits a program that is out of date.  Now object C,
which inherits B, is compiled (or recompiled, doesn't matter).
driver->recompile() is now called with B as its argument,
because B inherits an object, A, which has been destructed.
The driver object can now destruct B also, to ensure that C
will inherit the latest versions of both B and A.

As in LPmud, uncompiled objects that are inherited are compiled
automatically.

The recompile() function is not directly related to the
recompilation in situ functionality.  Rather, it is a way for
the driver to ask the mudlib a question: "Do you want to recompile
this object, B, before letting C inherit it?  If so, destruct it
yourself, following the proper mudlib procedures."

Since inheritable objects in the kernel lib are always stateless,
they can always safely be destructed and compiled again -- therefore
the recompile function in the driver object always destructs its
argument.  In other mudlibs, destructing an inherited object may not
be appropriate.

Regards,
Dworkin

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