[MUD-Dev] Re: PDMud thread summary
Jon A. Lambert
jlsysinc at ix.netcom.com
Sun Oct 25 21:51:03 New Zealand Daylight Time 1998
On 26 Oct 98, Niklas Elmqvist wrote:
Too many messages to grok. I thought I'd respond at random, even
though it may break your chain of thought. :P
> On Sun, 25 Oct 1998, Chris Gray wrote:
> > However, if I am understanding correctly, doesn't using this technique
> > preclude using any implementation language other than C++, (and that
> > everyone use the same C++ compiler) since external inheritance requires
> > consistent object layout and virtual function table format?
> Yes, it does. It works since the compilers I've come across don't do
> anything funky with the virtual function tables of subclasses.
An OO mud language needn't have any virtual tables. Virtual
functions and the like are C++ specific. You do have to settle on an
object format. Perhaps this might be a better place to start?
What properties do we desire a generic object to have?
> > How would modules written in the MUD-language match this layout? The
> > MUD-language and virtual machine could force all entities manipulated by
> > the MUD-language to inherit from whatever base class is the one chose
> > for the external inheritance level.
> Hmm, not sure what you're getting at here, but yes, the base class in the
> executable must be made adequate since it must be used for all accessing
> of the objects (at least on the driver level). And are we sure we will
> support MUD-language code modules on this level? IMHO, MUD-language is
> better suited to in-world stuff.
Are we talking about a language that just does simple scripting
(i.e. DLG, Mobprogs) , or a complete mud language here, like LPC,
MOO, Cool, ColdC. A simple glance at these drivers indicates an
obsession and attention to server language as opposed to driver.
That is to say, the former drives the latter.
> > Isn't that kind of restrictive? The net result of this, is "just another
> > C++ MUD" isn't it?
> Yes, but the alternative would be "just another C MUD", or what? Do you
> refer to some specific phenomenon?
See above... the driver's implementation language shouldn't be a
limiting factor in the design. You should be able to implement the
same glue in C, basic, pascal, C++, Java, Ada, etc. Much of
the stuff I've been reading here (although very interesting and
amazing) is very, very C++ and Linux platform dependent.
> > If that base class is changed in any way, *everything* has to be
> > rebuilt, possibly including all MUD-language code. Wouldn't that
> > completely invalidate any existing database?
> Well, my thinking is that external inheritance (sorry) would only be used
> for modules and events -- I've been concerned mainly with the driver level
> here. The database module(s) would build and use their own data
> structures, and would not be affected by any change in the base classes.
> Actually, trying to tie in database structures into the core would
> needlessly narrow our options.
The core/kernel should not need any state to be maintained for
itself. BUT.... it should "broker" state change requests between
the VM and DB. BTW, any DB from file-system to rdms to dbm
to oodbms could be supported from the same API. If there's any
interest and I have the time, I could ramble on for hours on ACID and
TP requirements and possible interfaces. ;)
> > What are the benefits that balance these downsides?
> I think I've gone over some before, but the main reason I see is that this
> is a neat way of using O-O concepts over shared lib boundaries with all
> that entails. AFAIK, there does not exist a good mechanism for exporting
> classes in shared libs. With this technique, we can have encapsulation,
> polymorphism and inheritance all working the way we want them even though
> our main functionality may be imported in dynamically loaded modules.
But we've been talking modules here with very little attention paid
to objects/classes/instances. Is a module a class? Can it be
instanced? Or is a module the one and only instance? Where is
> > I'd like to see databases portable from system to system. E.g. one
> > created on say, a SPARC UNIX box is directly usable on an X86 WIN32 box.
> > Since MUD-language code is likely stored in that database, it should be
> > similarly portable.
> Again, nothing in the core should affect anything in the databases. Sure,
> the modules are themselves dependant on the base class in the core and
> they all use inherited versions of the event class, but this does not have
> an impact on the database.
Agreed. Keep in mind ANY DB can be have the same interface wrapper.
If somebody wants to write an Oracle wrapper, great, a home-made DB
design, that's fine too. Also as someone else mentioned, I don't
think there should be any unecessary distinction between memory
and database, it's all storage.
--/*\ Jon A. Lambert - TychoMUD Internet:jlsysinc at ix.netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\ "Everything that deceives may be said to enchant" - Plato /*\--
More information about the MUD-Dev