[MUD-Dev] Object and class heirarchies -- are they really necessary?
Dr Richard A. Bartle
richard at mud.co.uk
Tue Mar 21 22:01:24 New Zealand Daylight Time 2000
J. C. Lawrence writes on 21st March, 2000:
>The Skotos guys (mostly Christopher Allen) made the point that at
>Skotos they instead essentially have only one object type, and
>everything is then an instance of that type. Thus player
>characters, NPCs, swords, rooms, bricks, pebbles, trees, sacks, etc
>etc etc are actually all instances of the same super-class
I do that in MUDDLE, too, although I extend it to cover
other, more esoteric things such as functions, timers and players
(not their personae in the game, but a representation of the actual
>My inheritance tree fans out into many small banrches, and then
>the branches then collect back together again (multiple inheritance)
>to produce the super classes.
Yay! Multiple inheritance!
I used to get slated terribly for using multiple inheritance.
The argument against it seemed to be "you can do that using single
inheritance if you twist it hard enough", which I never found convincing.
I'm glad MI is finally gaining acceptance.
>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?
Ah, I cheat - I only have one person ever add new code, ie. me,
and I know my hierarchy so well that I don't tend to make these kind of
I also have the facility for attaching methods to lower parts of
the hierarchy, eg. only to objects of class "combustible", which helps
limit the side-effects. That said, I still haven't quite got around to stopping
trees being an indirect subset of "food" (sigh).
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev