[MUD-Dev] Re: DevMUD: Inheritable modules

[Jon Leonard]

On Fri, Oct 30, 1998 at 02:12:22PM +0100, Niklas Elmqvist wrote:
>
> [Jon Leonard:]
> > My current thoughts on this:
> >
> > I don't want to use C++, because it doesn't have the object model I want.
> [snip]
>
> Not to be grumpy or anything, Jon, but... I thought that the DevMUD
> project would involve members on the list. I really would like to make a
> difference, I've tried to offer my view on things and I would appreciate
> if vital design issues such as this are discussed throughly.  I, at least,
> have tried to make a point about my design ideas being suggestions, not
> "laying down the law".

Hey!  An "I want" from me doesn't decide anything any more than:
"(Small voice: I still want to do it O-O. Wanto! Wanto!!! :)" from you
decides stuff.

At this point, I consider only one thing decided:  There will be a
DevMUD project.  That means that I'll write one myself _if_ no one
else wants to do one.

And for the record, I'm in pretty close agreement with what you've posted
after we get past the abstraction level of how modules communicate.

Surely choice of implementation language (Any using C calls vs. C++)
and a detail on logical busses (optional vs. mandatory) isn't that big
of a deal?

> C++ does not have the object model *you* want. Should there not be a
> discussion about the feeling of other potential contributors on this list
> (even non-contributor will probably have *very* useful things to say,
> given the talents on this list)? Or at least more motivation than your
> personal preferences.  If we can discuss it, I am sure we can come up with
> a much better and more objective solution.

I thought we were having just such a discussion.

> Now, in this case, I happen to agree with you (I did not earlier, but I've
> been convinced by your arguments, not by you overruling my opinions).
> However, the reason for me not wanting to use C++ in the DevMUD driver
> (there is of course nothing to stop module writers from using C++ or
> anything else in the modules) is not the object model -- it is that C
> calls (function pointers) are much more portable than C++ objects when
> used in other languages and between different compilers. *This* is the
> kind of arguments I am looking for.

I don't think I should include everything I've previously posted when I
make a comment like that.  I was mostly referring to part of my post from
Oct 20th:

] I think some C++ charateristics are incompatable with what we want to do:
]
] 1) The C++ object model is unique to C++, and using C++ objects from another
]         language requires writing wrappers that use C bindings.  C++ naming
]         conventions aren't even consistent between compilers, and prevent
]         other languages calling objects directly.
]
]         If we're going to have C bindings for things, (necessary for
]         supporting in-game languages like Perl, Python, TCL, etc.) then
]         I don't see the point in building separate C++ interfaces.
]

Here's the specific line:

] 2) The C++ object model doesn't lend itself to mix and match components,
]         in that it can require a recompile to change between logically
]         equivalent interfaces ("fragile base class problem").  This
]         prevents dynamic loading of modules, at least in some combinations
]         that I want to use.
]
] If there are good workarounds for these kinds of problems (and the consensus
] is that people want to use C++), then I'll ignore my distaste for C++
] (I've been burned more than once by C++isms on large projects) and use it.
]
] I have no objections to modules being written in C++ (or some other language),
] but I prefer interfaces using C calling conventions.  (extern "C" in C++)

I also don't like code inheritance, as I mentioned in a more recent post.
That's just a preference, and shouldn't keep us from using C++ if we wind
up deciding by voting or something.

> Of course, you may be speaking about your own prototype. In that case,
> you're entirely in your own right to say these things.

My prototype is little more than a demonstration that you can use dlopen
to assemble modules in a MUD.  (Ok, people are talking using it too.)
If it gives me some special authority, I'd like to know why.

> Anyway, I tried to outline my own thoughts about the basic architecture of
> the DevMUD driver (which were discarded, I might add). Could other people
> please offer their own thoughts about the driver architecture (thoughts
> are enough, not complete designs) the way they see it so that we all can
> reflect on them? We will probably get a much better architecture this way.

We certainly want to look at any thoughts any listmember has.
Non-listmembers too, but they're less likely to post.

At some point we have to discard some, but this is still that discussion
phase.

> (Okay, this might be an invitation to design-by-committee, but if people
> are to want to contribute to a project like this, they will want to feel
> as if they've made a difference. And not just to doing the grunt-work of
> coding the thing -- design and analysis, too.)

I expect that after discussing stuff for a while, some sort of team will
say, "Ok, this overall design sounds good, let's go and start coding."
(And prototypes don't count.)

Jon Leonard