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

[Phillip Lenhardt]

On Wed, Mar 22, 2000 at 03:14:27PM -0800, J C Lawrence wrote:
> On Wed, 22 Mar 2000 01:01:33 -0500 
> Phillip Lenhardt <philen at funky.monkey.org> wrote:
> 
> > On Tue, Mar 21, 2000 at 03:57:25PM -0800, J C Lawrence wrote:
> >> True.  That was one of the sources of the design requirement for
> >> Murkle that features must be programmable without requiring
> >> source access to any other objects.
> 
> > No matter how many times I read this design requirement--and it
> > has been many: I have read and reread nearly every thread in the
> > archive in which it appears--I always come to the conclusion that
> > it is either tautological or trivially false. Since both those
> > conclusions seem unlikely candidates for what you mean, I was
> > wondering if you could clarify.
> 
> Aye, the wording is not the best.  A better statement:
> 
>   In order to program any feature in the game source level access
> must not be required to any other pre-existent objects in the game
> that are not the direct recipients of the feature.  Ie.  If a
> feature is going to _directly_ affect only objects X, Y, and Z, then
> those are the ONLY objects that should need to be accessed.
> 
> Even that's not so great.  There were a variety of scenarios used to
> develop the basic concepts:

<scenarios snipped>

While very interesting and imaginative those scenarios (which I've read
before) just talk _around_ the basic concepts. I am going to try to nail
down some basics and then try to address my concerns in relation to them.

Objects have attributes. An object can add, delete or change any of its
attributes arbitrarily. An object can send messages to and receive
messages from outside itself. the contents of the messages are just
things that could be atribute value. An object can react to a message by
either changing its attributes, sending messages outside itself, or both.  
An object has _no_ direct knowledge of where messages come from or where
messages it sends out go to.

--BEGIN ANALOGY, DO NOT TAKE THIS SERIOUSLY--
As an analogy, consider a human being (Bob) as one of these objects. Bob's
thoughts are object attributes. Bob can think about whatever he likes.
Bob uses his senses to perceive the external world. The things he sees,
hears, smells, touches, etc. are messages from the outside. The things
Bob does, says, etc. are messages to the outside world. Suppose Bob sees
Alice (ie. he receives a sight message from outside world). Does Bob know
that Alice is another human being object? No. All he has is the contents
of messages from the outside world. Can he send messages to the
outside world intended for Alice and structured in such a way that if he
were the one to receive them he could understand them? Yes. Being an object
means being able to send messages of any structure to the outside world.
--END ANALOGY--

All in all a pretty grim picture. Objects exist in a kind of existential
void. Luckily, object-oriented languages are usually more featureful than
this. For example, languages usually implement messages in such a way that
an object can determine which other object, if any, sent it (eg. checking
the caller of a method). Languages also make it possible for an object
to verify the type of another object (eg. checking the class of an object).
But note, however, that even if a language didn't implement this features,
you could code as if they held true and as long as all the code played 
nice, your system would be equivalent to a system where these things 
were enforced by the language.

--BEGIN MAIN POINT-- 
My concern is that Murkle's spoofs and watchers force objects into that
existential void. If someone else can write code that wraps your object 
and doesn't let messages through, your object is useless and untrustable.
And if someone can only wrap spoofs and watchers around their own 
objects, why should they bother? They can just rewrite those objects.
--END MAIN POINT--



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