in Coldmud discussion meeting
Re: rehash: heirarchy
daemon@ATHENA.MIT.EDU (Fri Nov 19 11:17:09 1993
To: firstname.lastname@example.org (Alex Stewart)
In-Reply-To: Your message of "Thu, 18 Nov 1993 23:22:25 PST."
Date: Fri, 19 Nov 1993 10:00:43 -0600
From: Erik Ostrom <email@example.com>
> I'm also
> not quite sure why players are descendants of $container and
> $located instead of simply being descended from $box, but that's a
> minor point.
Just to expand a little on an earlier comment, since Jay doesn't seem
to want to flame about this right now:
The relation between me and the hat I am wearing is not the same as
the relation between a bottle and the water it contains. I am a
container in that my spleen is inside me, but I don't think that's
what most people intend when they make users descendants of
It would be nice to be able to consider these relations separately.
> Also, WHAT are you going on about with the $user thing?
Yes, Lynx, why is $person renamed to $user in your diagram?
Hm, after a little preliminary thinking, here's my attempt at a
user/robot hierarchy (whee, ascii art!):
| / | \
[$rpg_person] / | \
| \__ / | \
| `[$character] | \
$building_person | | \
| \ $guest | \
| \_____________ | \
$programming_person `$builder \
Sigh. The idea here is to separate "an object which has <rpg,
building, programming> commands available" from "an object which
handles connections and represents an actual user." So $character,
$builder, and $programmer each are determined solely by their
inheritance from $user and a person class.
$person means "an object which executes commands" and basically acts
like a person in some sense, whether a robot or a real user.
Not everyone wants RPG functionality, so $rpg_person and $character
should be easily detachable; $building_person should inherit from
$person or $rpg_person if it exists, and $guest should inherit from
$user or $character.
BTW, stuffing everything into a flat namespaces is really lame.
Just tossing out ideas (and one content-free remark)