[MUD-Dev] Re: DevMUD: Inheritable modules
jleonard at divcom.slimy.com
Wed Oct 28 15:37:02 New Zealand Daylight Time 1998
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
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
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.
More information about the MUD-Dev