[MUD-Dev] Re: PDMud thread summary

[Jon A. Lambert]

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 
state maintained?

> > 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   /*\--