[MUD-Dev] Re: DevMUD: Inheritable modules

[Jo Dillon]

Jon Leonard (jleonard at divcom.slimy.com) spake thusly:

> My current thoughts on this:
> 
> I don't want to use C++, because it doesn't have the object model I want.

  I'd say C makes sense for the basic engine; I personally would probably
end up writing my plugins in C++, but the plugin interface should probably
be C; C has something approaching an ABI whereas C++ emphatically does
not, and it would be nice if plugins compiled with different compilers
on the same platform would work.
 
> 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)

  I personally like this idea, where an interface consists of an array
of function pointers. It tends to make for efficient function calls :)
It also works well for communication between languages and for RPC.
I did some tests at some point (I don't have the statistics) which showed
that using this approach was as fast as using virtual functions
and /much/ faster than Java method calls, but about half the speed of
a non-virtual function call.
 
> This database of interfaces shouldn't be monolithic -- I don't want to have
> to know about all interfaces that someone else might define.

  Of course, you would want to know what interfaces were defined by
remote objects in a distributed mud. Perhaps it would be good to look
at COM or possibly CORBA here?

--
	Jo

Harmony - the project to create an LGPL Qt clone
http://harmony.ruhr.de