[DGD] Re: Couple DGD questions

[Stephen Schmidt]

On Wed, 10 Jun 1998, Frank Schmidt wrote:
> In the auto object, a static function behaves like a kernel function
> (kfun) _too_: It cannot be accessed by call_other(this_object(),
> "kfun_func"), _and_ calls to it in the auto object are _not_ redirected
> to any masked function in this_object(). This is true for ALL static
> functionnames in the auto object, not just the default functions
> specified by the driver you happen to override.

This raises the following design issue; suppose one wants to create
something like a heart_beat. Then one would want to have a do_heart_beat
function that would recursively call_out itself. If one puts this in
the auto object (which seems a natural place) then there is a problem.
If one makes it static, then it cannot be call_out'd (I think; not
sure about that but the tests I've done strongly suggest it), but if
you do not make it static another object can start it up with
call_other() which is Not Desirable. I see two solutions:

1) put the do_heart_beat() function outside the auto object, in which
case anything that didn't inherit the file you did put it in (perhaps
object.c?) could not have a heartbeat. You could, of course, make
heartbeat its own inheritable to get around that.
2) put the do_heart_beat() function in the auto object, make it not
static, and have the first line be:

    if (previous_object() && previous_object()!=this_object()) return ;

to guard against external calls that way. I lean towards the second,
since I'd like heart_beat to be globally available for purely
aesthetic reasons. Anyone see any pitfalls in that, or unrealized
gems of doing it the other way?
 
I had written:
> > Second, and unrelated; it is now the case that when an object is
> > compiled, create() is not called right away; it's called only
> > when the first function is called in the object.
 
> When a master program is
> compiled (I really prefer calling them blueprint because of my Master
> object..) 

I tend to use "master copy" to indicate this, but I agree that
blueprint is better... although blueprint implies that it will
be cloned which is not always the case. For example, rooms or
board objects tend to have the blueprint object be the one that
interacts with the mud world.

> Maybe, but I too missed that point. Any ref. to where in the docs this is
> explained?

In the Introduction document; that document lists all (I think all)
the functions that the driver will call, one of which is of course
create() or whatever you've reconfigured it to, and it's mentioned 
in the description of the create() function.
 
Steve





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