[MUD-Dev] Custom Server Roll Call?

[Chris Gray]

[Emil Eifrem:]

> So basically enforcing this would mean I'd have to use of some kind of
> preprocessor that confirms that all invoked exported functions have a
> corresponding definition somewhere in some other module? Unfortunately,
> that's the kind of extension I would much rather avoid. I think I have
> achieved the same effect with my "exported functions?"

That was one thing we talked about. What actually got implemented was
a scheme were each exported function was exported along with a string
which described in a brief, abstract, way, its interface. Each importer
did the same. The strings were checked at run-time to see if the
function does what the importer believes it does.

> I would really want to have basically everything contained in reloadable
> modules. I'm just so hooked on the "detach;compile;attach new" approach to
> a mud that has been repeated here so many times. (I'm also, btw, coming
> from a 100% hardcoded background (ROM) with a server that basically
> requires rebooting for every little change. Much like that favorite
> operating system we all love to hate.) I may ultimately end up with a
> server consisting of two modules: network and world, where world is an
> entire mud minus networking.

That would certainly work. Here, however, I'll suggest what I did: have
a fairly efficient interpreted language to define your world with. Then,
you have your own choices about how that language does information
hiding, inheritance, etc. For example, in my system, 'properties',
which are like class members in C++ (a big sort-of here!), are first-class
entities in the system. That means they have a value, and when I
reference a property on a 'thing' (think generic object), the lookup is
done at run-time based on the property. Thus, I can have the properties
completely hidden inside "modules", but other code can add their own
hidden properties to the same 'thing's. Code that doesn't know the
definition for some property can't even tell that the property is
present on the 'thing' - it can only examine/change the values of
properties that it knows about. Doing this is certainly more expensive
that a fixed offset reference like C++ or Java does, but is likely faster
than having to convert everything to and from strings all the time.

I'm sure there are other solutions, too. You just might have to throw
away some of your basic assumptions about how you are doing things.

[In case you want to pursue this further, my complete docs are online
on my website - be prepared for lots of reading, however!]

--
Don't design inefficiency in - it'll happen in the implementation.

Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA
               http://www.GraySage.Edmonton.AB.CA/cg/


_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev