[MUD-Dev] Object and class heirarchies -- are they really necessary?

[Kevin Littlejohn]

>>> Lazarus wrote
> This is where I wound up.  My latest design concluded with a base class of
> 'mud_thing' from which everything else was derived.  I thought it was cute
> to pick up my test character (could be used for trouble makers as well)
> and put him in my pocket.

This approach, I've got to say, seemed completely natural - it was a first
principle in the very first design docs for Moebius.  I'm somewhat
surprised anyone builds these days in systems where objects _are_
fundamentally different.  An object is an object is an object.

However ;)  I've got to ask - what goes on in the middle of the tree?  All
well and good to say "things start from a common ancestor, fan out, then
come back together", but what does that actually lead to in practice?

I've posted on this subject before - Moebius is fast approaching a common
inheritance line, then various smaller building blocks for various groups
of characteristics - want a wooden object, inherit from wood, want creature
stats, inherit from creature, that sort of thing - is this the approach
that the above leads to, or are there other ways to organise the class
hierarchy that work better?  Skotos people?  Others?  Before I commit
myself to a potentially flawed design? ;)

> > When your entire inheritance tree (from an object's perspective) is
> > that you all descend from the same super-class -- how do you handle
> > multi-user security and access controls for editing the consituent
> > components of that super-class?
> > 
> 
> What is your question?  You handle security of any instantiation the same
> independant of whether it is multiply derived from multiple base classes
> or derived from a single super class.  Or, are you proposing online
> editing of the base class definition?  Now that would be one heck of a can
> of worms.

We already do it - introduce new attributes, and remove old ones, in the
base class and have the changes reflect immediately (give or take
potentially dodgy cacheing ;).  That runs smack into "don't give access to
change these to anyone you can't drive over to and thump" territory - once
you can enforce access restrictions between objects at the mud level, you
then have to make social/political/people decisions about who is trusted
and who isn't - you can't fully protect the mud from the ravages of an
insane creator with access to the base object.

It is _very_ handy for being able to change the world physics without
restarts - introduce new concepts (like weight, size, etc) on-line, tinker
with them, remove them again, without actually disturbing
players/builders/visitors.  At least in the small scale, and I'm hoping to
keep a 'sandbox' ability somehow so changes can be modelled online in a
safe environment, then switched through to the rest of the mud, once it
grows.

KevinL



_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev