[MUD-Dev] Re: PDMud (was Re: Bruce Sterling on Virtual Community goals)

[Chris Gray]

[Niklas Elmqvist:]

[I hope I'm not too out-of-date on my responses here!]

[*much* snipped - no comments from me]

 >I agree. The GC-part is not a must, but would be nice. However, if we do
 >want it, it should be something we add from the beginning, yes?

I suspect it would have to be. If we want non-programming-gurus to be
able to write scripts directly in the language, they shouldn't have
to worry about allocation/freeing of things. So, either garbage collection
(something I know very little about) or reference counting should be
used (are there other alternatives?). We should be clear about just
what it is we are keeping track of, however. In a system like Java,
it is all sorts of things, all kept in system memory, that are GC'ed.
The other component that needs keeping track of is the database. As an
example, in my system it is only the database entities that are ref-counted,
since there isn't anything else that can dynamically be created. I
keep all code, arrays, strings, tables, grammars, etc. in the database,
so that makes sense. PDMud will be different, no doubt, so the question
will have a different answer. However, I suspect that answer needs to
be settled before a lot of other questions can be asked.

 >Well, how would you go about using C++ objects in a C++ module loaded by a
 >C program? Never mind, I assume you have the answer :)

I'm not a C++ expert, but I do know a fair amount about compilers and
run-time systems. Your question is valid, I believe. Calling C++ code
from C isn't a big deal as long as you use "extern C" on the declarations
exported by the C++ stuff. What is a problem is the C++ run-time system.
Unless you are *very* careful in writing your C++ code, you will be
invoking that run-time system, and if it hasn't been setup correctly,
things will break. If the C++ runtime is completely self-initializing
on its first use, it isn't a problem, but I would need assurance that
that is the case before I stopped worrying about it.

 >Admittedly, you need *some* kind of coordination between modules. The
 >ParserModule must know the acceptable commands supported by the
 >other modules (or does it? Maybe this could be polled by a message from
 >the ParserModule: "Okay, send me your command grammars along with a way of
 >packaging this into a request you can capture.").

I'd suggest you do it the other way around. The various modules like
client graphics control, magic, movement, on-line building, etc. all
tell the parser what actions they have, and the words for them, etc. The
parser then uses this information to figure out what the user is trying
to do. When it is successful, it simply calls the methods associated
with the actions that it has decided on.

--
Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA