[DGD] Re: Couple DGD questions

[Frank Schmidt]

On Tue, 9 Jun 1998, E. Harte wrote:

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

No, as you describe it, that is the way it works for other objects BUT the
auto object, and an object may access its own static functions through
call_other, i.e: call_other(this_object(), "static_func") works.

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.


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

No, sorry, but this will not disable his security IF the security call is
made in the auto object, but it will override the call made in an
inherited program. This is ambigous, and is of course not wanted. However,
I dislike overuse of nomask due to lack of knowledge about kfuns. In many
situations, nomask creates a false sense of secureness, overlooking the
more important holes.

I set a BIG questionmark (?) to this way to deal with security too.
Instead of having the valid_ functions in each and every object, make a
daemon which any object may call_other() and query about security issues
and similar. 

(An equivalent of MudOS Master object is nice, or you may split it up in
several daemons. The way I deal with it is a master.c object for
simple queries, and a global.c object for call_out(), heart_beat(), etc,
global issues. The main point is to globalise functions and datas in
sentral objects.)

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

This is true for redefines kfuns in the auto object too.

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

Nomasking a function makes it impossible to overload in an inheriting
program. However, that is not the same as static, private or kfun, since
you can still access a nomasked function!

And.. Your wishes have come true! It is possible to make the functions
behave like kfuns, just declare them static in the auto object. And it is
VERY convinient, flexible and elegant. :)

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

Arrgh. I didn't know this. Thanks for the information, it was new to me,
a simple test showed that it was correct. When a master program is
compiled (I really prefer calling them blueprint because of my Master
object..) the create function is not called before the first function is
called in the object, and for clones the create function is called right
away.

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

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

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

If it suits you, there should be no problem with that.
I guess I'll implement the same thing myself.

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

I can't really see it nescessary in _any_ circumstance. Please name one.
Of course it is perhaps better to support it than not support it at all.
But why just for master objects, why not for clones too? I suspect the
answer has something to do with DGD-Internals...

> 
> Hope this helped,
> 
> Erwin.
> 


PS. I ALWAYS test things before making assumptions about things, never
trusting documentation or others arguments. It is essential to know _all_
the details and see for yourself.


Keep on DGD-ing!

Frank Schmidt




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