[Home] [Groups] - Message: [Prev in Group] [Next in Group]

nu.kanga.list.mud-dev

8733: [MUD-Dev] Re: DevMUD: Inheritable modules

[Full Header] [Plain Text]
From: Jon Leonard <jleonard@divcom.slimy.com>
Newsgroups: nu.kanga.list.mud-dev
Date: Thu, 29 Oct 1998 16:40:16 -0800
References: [1] [2] <-newest
Organization: Kanga.Nu
On Thu, Oct 29, 1998 at 06:53:29PM +0100, The Arrow wrote:
> On Wed, 28 Oct 1998, Jon Leonard wrote:
> > On Wed, Oct 28, 1998 at 07:20:20PM +0100, The Arrow wrote:

[modules, DevMUD, OO techniques]

> > Interface inheritance:  Useful for making modules interchangable.  Specify
> > 	the interface you want, and any modules that match it (or are a
> > 	superset) will work.  I like this, and plan to use it for a telnet
> > 	module working as a superset of a socket module.
> 
> 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.

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.

Jon Leonard