[MUD-Dev] Re: DevMUD: Inheritable modules

[Chris Gray]

[Joachim Pileborg/The Arrow:]

[...description of mudule interfaces...]

First, let me say that I like what I've seen here. The general approach
looks good to me, although I don't follow the intent of some of the
details. I would suggest, however, that we use the phrase 'a module
implements an interface' rather than 'a module inherits an interface'.
This is consistent with the Java terminology for the same thing, and
avoids suggesting that anything in the way of data structure is
inherited.

 >The function array is a NULL terminated array of pointers to
 >interface_function structures.  The interface_function struture contains
 >the following fields:
 >  o Funciton name
 >  o Pointer to the function
 >The function name is a predefined constant that is interface specific.
 >For example:  The Net basic module could have the following function
 >names:  MOD_NET_CONNECTTO, MOD_NET_WRITETO, and MOD_NET_READFROM.

I'd like to add parameter and result type information. Even if this
stuff is statically predetermined, having it available at run-time is
useful if there is a MUD-internal language that can display it. Or
allow an on-line programmer to call a module exporting it!

 >MUDs must have at least the following interfaces to be DevMUD compliant:
 >  o Module
 >      The Module interface contains functions to get info about the
 >      module and configuring the module.
 >  o Net
 >     The Net module is an abstract interface, containing just dummy net
 >     functions.  Modules inheriting this interface must provide real
 >     implementations for these functions.

Are you really speaking of what a MUD must implement in order to be
compliant with DevMUD? Or are you speaking of what modules must
implement in order to be usable with a DevMUD core? In the latter case,
why must all modules implement the Net interface?

 >The following interfaces are considered standard, and should either come
 >with the DevMUD package, or be easily found and added:

Lots of room for discussion here. I'm sure there will be!

 >If a module inherits an interface not in the interface database, the
 >module is unloaded and an error message should be logged on the console
 >and sent as a message to all loaded modules.

Why? If a module is loaded, and it implements an interface that no-one else
has heard of, so what? Perhaps the very next module to be loaded needs
that interface, and the two are being loaded as a pair. Just add the
interface to the table of interfaces, and have it ready for use. I also
think that the only interfaces that the core need already know about are
those which it exports, or which it generically requires of all modules
(e.g. your Module interface).

After thinking through this, and some earlier discussions, too, my
previous idea of having a header file containing prototypes for the
interfaces isn't needed at all. As Joachim says, each interface is
self describing, and the core simply matches up modules that export
such an interface with those that require it.

Just how the core matches up requirers with providers still needs some
discussion. This is a good start!

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

Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA