[DGD] Re: Couple DGD questions

[Frank Schmidt]

On Wed, 10 Jun 1998, Stephen Schmidt wrote:

> 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:

Functions which you call with call_out() in DGD may be static and/or
private, as with most functions called directly from the dgd driver. Makes
security for the driver object, user object and call_outs very simple; by
use of static.

BUT, that is not true in the auto object. Static functions in the auto
object are by definition kfuns, and not callable through call_other() from
any object, neither from call_out() calls.

Also I strongly suggest you override the call_out kfuns in DGD since
they call functions with unlimited resources, and maybe you need to setup
the correct this_player() or something similar prior to the call. And
there is no global registration of call_outs, plus it is limited.


> 
> 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 ;

Only previous_object() check is nescessary to see if it was called
directly from the driver, and the driver alone (e.g. call_out).
Previous_object() will return 0 if the call was a call_out() or similar
call.


> 
> 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?
>  

Hmm, the way my global object do is, is to store an array of objects that
have heartbeats. Then I only need one "dgd-call_out", instead of using
one "dgd-call_out" for each object in the game needing a call_out.
Remember, call_outs are a limited resource too. Also, it makes it
easy to setup things prior to the actual heartbeat without using up
namespace in the auto- or any other object, e.g. set this_player() to
"this_object()" if it is "living".

If you do, however define heart_beats in the auto object, e.g: 
(cannot use static since it will become a kfun, unreachable to call_out)

nomask void __do_heart_beat() {
  if (previous_object()) return;

  ... /* (optional pre-stuff) */

  heart_beat();
}

Remember the nomask to this function, or else it is easy to mask in an
inheriting program. And prename the function with __, _F_ or something
similar, just to hide it. Much cleaner :)


> 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.

I disagree, a blueprint doesn't imply that you need a clone. It is the
clone that needs a blueprint. So the blueprint always comes first, thus
there is always a defined time in which a blueprint may exist but not its
clones. And if you don't need'em, just use the blueprint, eh, but _using_
a blueprint may sound bad, but so does master program too. Anyways, as
long as people understands me when I say: master program, blueprint and
Master object, I'm happy. :)

> 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.

Thanks! Dunno how that one slipped my mind..


Frank




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