[MUD-Dev] Re: DevMUD: Inheritable modules

[James Wilson]

[Jon Leonard]
>> >I don't want to use C++, because it doesn't have the object model I want.

[James]
>> can you elaborate?

>More or less what I've said in other messages.  You can't change the
>implementation of a base class without (usually) forcing a recompile, you
>can't query objects for what methods they support, you need to know object
>interfaces at compile time.  That sort of thing.

okay. of these, only the last do I disagree with - not because you're wrong, 
but because I think it's a GOOD thing. That is, when I compile something
in C++, I know that the compiler will tell me if I'm trying to invoke
methods on objects that don't support them. The alternative would be to 
allow foo->bar () even if foo isn't known to support method bar (), and
throwing an exception (or something) at runtime. This sounds like a nightmare
of intermittent errors to me, but then I'm a big strong-typing fanatic.
 
>You can do these things in C++, but you wind up doing it in parallel with
>the C++ module hierarchy.  Why not do it in a language-portable way?

hmmm, yes, I mainly agree. This does raise the question, though, of _what_
languages and how. If C and C++ are to interoperate, this is straightforward
and we can write the kernel in either one, object model aside. I am dubious
about the possibility of having other languages cooperate without some
heavyweight abstraction such as CORBA or Gamora's buses. That doesn't mean I'm
necessarily against such a thing, I'm just concerned about efficiency.

What are people's thoughts on this? Should we try to come up with something 
"language agnostic", as the Casbah project (built on Gamora - see Nick's post
of his communique from the Gamora guy for a pointer) is attempting to do using
Scheme? There were some interesting messages on their mailing list about
troubles they were having with language agnosticism, which I will attempt to
find again and post to mud-dev.

>> did you see my proposal for how this could be done very easily in C++? the
>> mapping is pretty straightforward.
>
>The recent one with the modules full of declarations, not the earlier post
>about using extern "C"?  I've read all of the messages on MUD-Dev about
>DevMUD (usually several times -- it's hard to remember everything reading it
>only once.)
>
>It looked plausible, but my primary point is that if we're going to invent
>a different model to deal with dlopen sorts of issues, we should invent one
>that works for C, C++, or nearly any other language.  I prefer to write
>modules in C, and if someone else writes in C++, we should interoperate.

there's nothing in what I proposed that would prevent that. Just write a C++
stub for your C functions and export that as a named interface. Your scheme
using void function pointers and mangled names requires C++ modules to write a
series of C stubs for their methods, so neither scheme is more general. Perl,
Python, Java etc all can bind to C++ as well as to C, so there's no difference
there. But I think we're putting the cart before the horse.

We need to step back a little bit and talk about goals. Are we looking
for language agnosticism? Anything with C/C++ bindings? Distributed
processing? I think these questions need to be answered before we can talk
about intermodule protocols.

James