[DGD] Re: Couple DGD questions

[E. Harte]

On Tue, 9 Jun 1998, Stephen Schmidt wrote:

[...questions about kfuns...]

Making a function static in the auto-object only has an effect on
call_other() type of calls to such functions.  I.e: if "foobar" is a
static function in your auto-object then "someobj"->foobar() will return
0, _unless_ "someobj" has defined its own foobar() function which isn't
static.

So, to consider your write_file() and valid_write() example, I'd either
make the valid_write() nomask, or private to the auto-object, yes.
Otherwise something like the following could disable your security:

<auto-object>
static int
valid_write(string filename)
{
}

static void
write_file(string filename)
{
}
</auto-object>

<other-object>
static int
valid_write(string filename)
{
    return 1; /* of course ;) */
}
</other-object>


There is another situation where kfuns are showing how they're different:

  If you are using a certain kfun in the auto-object which you have -not-
  redefined, for instance you're using this_object() or previous_object(),
  then no matter how hard you try to redefine those in another object, the
  code in the auto-object will continue to use the -kfun- and not the
  redefined version.

Sometimes I wish there was a way to make static functions in the auto-
object behave the same way without having to nomask them. :-)

> 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. This caused me
> a great deal of headache tonight when I couldn't figure out why
> create() was not running, which was solved when I RTFM.  :)
> Question is, why was this changed?

What makes you think this changed?  As far as I remember, the 'create'
function (or whichever name you pick for this function) was for non-clones
always called just before you tried to call any other function in the
object for the first time.

> It seems unintuitive for
> master copies of objects not to invoke create(), I find myself
> having to code around it (not hard to do) but in general I do
> not see a way for the mudlib programmer to alter this behavior
> except to have compile_object() be redefined and call some function
> in any non-clone object it compiles. Would there be a Bad side
> effect if I did that?

It would in many many cases be entirely unnecesary.  For instance for
objects that are only used to make clones of, or to inherit, the usual
ones for rooms and treasure-objects, or whatever.

Hope this helped,

Erwin.




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