[MUD-Dev] Re: DBMS in MU*'s

[J C Lawrence]

On Sun, 19 Jul 1998 20:46:15 +0200 
Asmodai <Jeroen> wrote:

> At 19:37 19-07-98 , you wrote:

Please use full attributions that identify the original poster.
Attributing to "you" is not good enough.  See:

  http://www.kanga.nu/~petidomo/lists/mud-dev/index.html#rules

and rule #5 in particular.

> A ORDBMS would be better than either a OO- or R-DBMS alone in my
> humble revised opinion as objects (or items and such) are related to
> a person or location, but can be children of one parent. 

This depends on your object model.  It can be true, or might not.
There are (dis-)advantages both ways.  Consider the implications for
user programming for one.

>> How do I implement an object model that specifies what objects
>> provide direct objects for various verbs?  There isn't a one-to-one
>> mapping between classes as defined above and direct-object-classes.
>> For example, say we have a class liquid_container; now both a
>> wineskin and a crystal goblet are liquid_containers.  But one
>> provides a direct object to "break" and one does not.
>> 
>> Multiple inheritance may provide a solution.  That is, I create an
>> empty table (class) "fragile" and nestle it under "object".  Then
>> the goblet inherits both "liquid_container" and "fragile".  And if
>> someone tries to break it, we look to see if it's a member of
>> "fragile" (or "fragile*" if I have subclassed "fragile" in the
>> meantime).
>> 
>> I'm worried that this will cause a huge explosion in the number of
>> tables, though.  Plus an awful lot of ugly special case code in the
>> server.

> I understand yer concern, but is a 'condition' table (or something
> like that) which lists the states an object can be in not the
> solution then? I mean, create a table with entries like:

> rock, glass, velvet, wood and paper and assign values about the
> subject being able to break, torn apart etc...

I'd suggest an analogue of Java interfaces would be a much more native
approach.  There's a fairly decent article in this month's C++ Report
(might have been CUJ, but I don't think so and the mags are at home)
on implementing interfaces under C++ which is worth reading.

> This would eliminate multiple tables and generally provide a good
> addition to the MU*.

I see horrors when you start to get:

  volcanic_glass, silicate_glass, pyrex, lead_crytal, etc.

--
J C Lawrence                               Internet: claw at null.net
(Contractor)                               Internet: coder at ibm.net
---------(*)                     Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...