[MUD-Dev] Re: DevMUD: Inheritable modules

[Jon Leonard]

On Wed, Oct 28, 1998 at 07:20:20PM +0100, The Arrow wrote:
> There have been a lot of talk about modules, how to implement them, and how
> to send messages between them.  But so far I haven't seen anything about
> inheritable modules.  I know it wouldn't be trivial to make a good
> implementation, but once done they might make DevMUD even more OO and
> extensible.  What do you think about it?

I don't want to do OO just for OO's sake.  I take the view that different
projects benefit from different programming techniques, and I don't see how
some of them help us here.

So I'll list some Object Oriented properties and which I'd use, and we'll
see what people think.  OO by itself is ambiguous:  C++'s model is different
from Objective C's, which differs from JAVA, CLOS, Smalltalk...

Encapsulation:  We don't want the internals of modules to be important to
	how they get used.  It's just the interfaces that matter.  I think
	DevMUD modules should definitely provide encapsulation.

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.

Polymorphism:  Same function, different arguments.  At least conceptually
	the same function.  Exporting multiple things with the same name
	with different function prototypes should be fine in DevMUD.
	(I'm assuming an array of function structures, here.)

Multiple instances:  It's often nice to have more than one of an object.
	Unfortunately, dlopen defeats this.  Calling dlopen on the same
	name a second time just returns the same handle.  If we want this
	functionality in DevMUD, we'll have to impose it as internal module
	structure.

Code inheritance:  Using language support to have calls to one object
	execute code from another.  This one I don't like, because it
	breaks encapsulation.  Consider if I have a class squarestuff,
	which exports two functions:  F, and F_1.  F calculates the
	square of a number, and square_1 calculates the square plus one.
	Reasonable definition, right?  Unfortunately, if I try to inherit
	to make a cube class, and override F, the behavior of F_1 can be
	many things:  It could still be x*x+1, if squarestuff's F_1 didn't
	call F.  It could be x*x*x+1, if it did.  It could be something
	totally different -- squarestuff might mix and use memoization or
	something.  The peculiar interactions that result from code
	inheritance make me try to avoid it.

That's more or less my preferences on OO design as regards DevMUD.  I want to
do this with C function pointers as the basic communication primitive for
flexibility.

Also, there has been some discussion using the simple-minded prototype I
have running on mud.slimy.com on port 2121, so I've upgraded the command
set a bit, tweaked for robustness, and started logging for the purpose of
collecting DevMUD ideas.

Jon Leonard