[DGD] Private static functions and object sub-types

[Steve Wooster]

I don't intend to allow anything other than the driver or auto objects to use 
call_touch(), so I figured it'd be nice if attempting to do so resulted in a compile error 
rather than a runtime... (that way you know that your object can't possibly work 
before it ever starts running) So I just tried adding
private static call_touch() {}
to the auto object, thinking the static modifier would make it act like a kfun, and the 
private modifier would make it inaccessable. Unfortunately, it looks like the private 
keyword stops it from acting like a kfun. Is it possible to prevent objects from using 
certain kfuns at compile time without resorting to pre-parsing the LPC file?

There's one more question that's been nagging me, and since I'm already writing this 
e-mail, I figured I'd ask it too: (I did check the latest windows DGD zip (1.2p4), but 
didn't see the sort of apply I was looking for in introduction.txt)
I don't don't have the experimental DGD version, so I was just curious if there's an 
apply in the driver object to translate the path given for something like:
object "/object/type" ob;

For example, if your mudlib provides the illusion that an object's path name is 
"standard://room.lib" when DGD considers its real path name to be "/std/room.c", is 
there a way of making sure that people have to type
object "standard://room.lib" room;
rather than
object "/std/room" room;
? (since the end-user should have no idea the latter even exists)

This is important for an idea I have... Why not split every object into an inheritable 
and a clonable (which merely inherits the inheritable), and have your core library tell 
the mudlib that they're the same object? If you do it right, you could make a mudlib 
that allows full persistant recompilation while providing the perfect illusion that any 
object can be both clonable AND inheritable simultaneously. :)

-Steve Wooster