[DGD] Simul-kfuns

[Dread Quixadhal]

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.

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.

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

Sent from Mail for Windows 10

From: bart at wotf.org
Sent: Monday, May 7, 2018 11:54
To: All about DGD and Hydra
Subject: Re: [DGD] Simul-kfuns

On Sun, 6 May 2018 16:52:36 -0500, Larry Moore wrote
> My issue is, that I didn’t want to bloat the auto object with all 
> of the simul-kfuns. However, having a simul-kfun file included in 
> the auto object doesn’t allow you to compile the individual simul-
> kfun file, since it is in the auto object and the auto object is in 
> all objects so you end up with an endless loop, so you can only 
> compile the auto object to find out if your simul-kfun file has an 
> error in it. 

If you want something which works functionally similar to what simul-efuns do,
whatever they are defined in will have to be inherited by all objects, else
the 'simul-efuns' will not be available in every object.

The consequence is that it is by far easiest to put them in the auto object,
but there are alternatives, you can create a special 'second level auto
object' for this purpose. You may want to take a look at gurbalib and how it
manages /sys/lib/safun, which to some extent tries to implement this.

> I suppose my issue is that I have been coding in MudOS 
> so long, and our plan is to convert our MUD that has been running 
> for 20 some odd years from MudOS to DGD, and I wanted to make the 
> transition as easy as possible for my staff. If I have to code the 
> simul-kfuns in the auto object, then I can do that, I was just 
> wondering if there was any other way.

That is not an easy task, and you'll have to be quite familiar with DGD.

Way of the Force (https://wotf.org/) is based on a very early lpmud 2.4.5
derived lib, and still feels quite similar. Getting that to work as well as it
does took many years, in part due to having to build the required DGD
knowledge on the way, but also in part because some assumptions which work
well on mudos (and other traditional drivers) do not work that well on DGD,
but are used a lot in 'classic' lpc code. One example is using a .c file both
as an inheritable and a clonable (through one can make this work as Felix did
in cloudlib for example), but there are a few more.

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

____________________________________________
https://mail.dworkin.nl/mailman/listinfo/dgd