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

[Chris Jones]

J C Lawrence wrote:
> 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?

	It seems to me that one way around this is to do something just
slightly different from what you're proposing, but before getting to
that, let me go off on a tangent to explain where I'm coming from.  

	I'm a MOO devotee -- I've been playing with it for about 5 or 6 years
(so I was there for the end of the heyday); I run one; and I like the
language.  What I don't like, however, is the default LambdaCore (I
should note that MOO has the idea of a separation between server -- the
VM that interprets the language and provides the low-level functionality
-- and database -- the run-time modifiable environment that's where all
of the interesting stuff is; LambdaCore is the core database that most
MOOs use, in some version): it's excessively crufty and virtually
incomprehensible in places (particularly the mail system), and it's
exceedingly difficult to keep up-to-date with changes and to modify it. 
In short, it's a classic example of programming that happened
organically, without an overall plan or, in many parts, any
documentation.

	So, I've been thinking about getting some people together to code a
very small, modularly extensible Core that could (but wouldn't have to
be) LambdaCore-compatible.  

	One of the things I'd very much like to implement is the idea of
capabilities (or packages), such that you could create, say, a Capable
Object that could have a Capability attached to it at an arbitrary time
by someone with appropriate permissions, and suddenly, it'd know how to
do something it didn't know how to do before.  For example, let's say I
have a Capable Object, and I want to turn it into a safe: what I could
do is plug a Containing Capability into the object, so it now knows how
to contain an object -- you can put something inside it, you can remove
something, and you'll get (reasonably) sane results.  Then, let's say I
add a Locking Capability to it, so that I can lock it, and it'll only
open when I let it.  By using modules that can be audited for security
ahead of time, we can ensure a higher degree of safety for the objects
themselves.

	I should note that there's no need to have a flat objectspace, either
-- there's no reason why kids couldn't inherit their ancestors'
capabilities (i.e. make the safe generic, and then all of the kids would
themselves be safes, and you could plug in, say, a Self-Detonating Bomb
package to one of them, and then you'd have a safe that explodes when
you get the combo wrong): instead of making the objectspace fully
hierarchical or using multiple inheritance, you can get the best of both
worlds this way.

	I'd be interested in any comments.

	CJ



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