[DGD] Simul-kfuns

[bart at wotf.org]

On Mon, 7 May 2018 14:34:20 -0700, Dread Quixadhal wrote
> Just to add my 0.2 cents…
> 
> I think there are three reasons people use simul-efuns.  One is to 
> override driver efuns so you can layer your own security, or change 
> behavior, without needing to mess with the driver.  That’s a good 
> reason, and many times it’s a real PITA to custom-edit your 
> driver’s source so it can inspect LPC objects when a simul-efun 
> override can just do that part and then call the underlying efun.

Thats certainly an argument on mudos, but on dgd not so much as the auto
object does this already in a slightly different way, as the functions are
inherited instead of getting redirected by the driver to some specific object.

> 
> A second reason is that they’re so widely used, that it makes 
> sense to just have them available all the time.  Things like sprint()
>  and a reversible explode() are great examples, if your driver 
> doesn’t already have them as efuns.

Those can go in the auto object, but see below..

> 
> Then there’s the third reason.  Lazy builders and coders.  
> There’s no question that it’s simpler to NOT have to design an 
> object hierarchy and just toss things into the simul-efun object 
> whenever you want.  It’s also nice for lazy coders, since they 
> don’t have to remember “scary” or “hard-to-type” 
> constructs like TERMINAL_D->terminal_size(), or whatever.  In MudOS, 
> there’s no performance penalty for doing this, and most mudlibs 
> are not persistent, so the only real annoyance is having to bounce things.
> 
> That third reason is, of course, a bad habit to get into.  But 
> it’s one I suspect many MudOS folk have, and breaking them of it 
> might take some time and patience.

Thats also what experience tells me, yet, leaving that habit of bouncing
things to get a change working is really the first thing you should do when
trying to move something to dgd. The main reason is that it is difficult
enough to get this to work with a ported mudlib, and postponing this just
makes things more difficult in the end, at least that is my experience. The
main reason is that you should from the start write all new dgd specific code
to support it, or find out much later that you made some decision somewhere on
the way which makes it very difficult.

> I suspect 9 out of 10 times you 
> want to make a new simul-efun, you REALLY just want a function 
> that’s easy for lots of game-level code to get to, which could go 
> in a domain object, or a daemon.  It just requires extra typing to 
> use it that way.

Its essentially why I implemented that /sys/lib/safun stuff on gurbalib, it
just lets you drop files in there (or plugins like the sprintf one at
https://wotf.org/downloads/gurba/plugins/) and use a 'warmboot' command to get
the code active, but it exists mostly because it is convenient and lets people
share such functions easily. Last time I checked, current gurbalib still
supports this kind of use.

Bart.
--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/