[MUD-Dev] Re: DevMUD: Inheritable modules

[Jon Leonard]

On Thu, Oct 29, 1998 at 09:00:20PM -0500, James Wilson wrote:
> 
> On Thu, 29 Oct 1998, Jon Leonard wrote:
> >On Thu, Oct 29, 1998 at 06:53:29PM +0100, The Arrow wrote:
> 
> >> It was something like this I thought of when I wrote the mail.
> >> The problem with interface inheritance, is how to export the interface.
> >> If the modules is written in C++ and we are using external inheritance
> >> (as described by Nicklas) the subclassing should be pretty simple.  But how
> >> should the driver know what interface (and module) to use runtime?
> >
> >My current thoughts on this:
> >
> >I don't want to use C++, because it doesn't have the object model I want.
> 
> can you elaborate?

More or less what I've said in other messages.  You can't change the
implementation of a base class without (usually) forcing a recompile, you
can't query objects for what methods they support, you need to know object
interfaces at compile time.  That sort of thing.

You can do these things in C++, but you wind up doing it in parallel with
the C++ module hierarchy.  Why not do it in a language-portable way?

My thoughts on the matter would look something like:

struct func {
	name *funcname, void *funcpointer, char *type_info;
};

Modules would export an array of these, more or less like this:

struct func interface[] = {
	"get_message", get_message, "char*(char*,int,int,int)"
	/* more like that */
	NULL, NULL, NULL
};

Choose your type to name mangling to taste.  There might be other elements of
struct func, like a documentation string, too.

> >An interface should have a name, and an array of function structures
> >like those exported by modules, except without the function pointers.
> >
> >We should have a source verifier that checks that the claimed interface
> >(name-mangled version of the function, or whatever) matches the prototype
> >of the function pointer.
> >
> >There should be a separate collection of defined interfaces, so a module
> >can just say "I implement interface X" (this can be verified, of course)
> >
> >This database of interfaces shouldn't be monolithic -- I don't want to have
> >to know about all interfaces that someone else might define.
> >
> >Explicit interfaces shouldn't be needed to make runnable MUDs, just
> >helpful in configuring them.
> 
> did you see my proposal for how this could be done very easily in C++? the
> mapping is pretty straightforward.

The recent one with the modules full of declarations, not the earlier post
about using extern "C"?  I've read all of the messages on MUD-Dev about
DevMUD (usually several times -- it's hard to remember everything reading it
only once.)

It looked plausible, but my primary point is that if we're going to invent
a different model to deal with dlopen sorts of issues, we should invent one
that works for C, C++, or nearly any other language.  I prefer to write
modules in C, and if someone else writes in C++, we should interoperate.

Jon Leonard