MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: MI

Followup to:  <Pine.LNX.3.92.960511021814.30579A-100000@phish.nether.net>
By author:    <warp@phish.nether.net>
In newsgroup: local.moo
>
> Yeesh i've read a TON of stuff about adding MI and i keep asking
> myself why not just give all objects the ability to use (and become)
> features?  That way if you want something on a object you can pick
> and choose what features you want and what features you don't want.
> 

I think you are missing the point of MI *completely*.  This is yet
another example on using object-oriented programming without using an
OO language, resulting in klugy and inconsistent paradigms.

MI is the capacity of a class to belong to more than one parent
class.  In a template-oriented language like MOO, a class definition
is itself an object (often referred to as a "generic" object).

In LambdaCore, there is a generic for a movable object called $thing.
There is also a generic $room which is a player visitable location.
However, a relatively frequently hack on LambdaMOO is a *movable room*
that can be picked up and moved around.

In an MI language, the movable room is simply a class having both
$thing and $room as parents.  In LambdaMOO it requires making a copy
of the definitions of one of the objects, which is hideously ugly.
Your proposed system would be somewhat better, but would completely
break the OO paradigm, since $thing and $room would no longer both be
parents.

A slightly more esoteric hack I was working on once was a vegetable
that would turn into a different object once picked up -- the status
of which would depend on the past history of the object.  The
situation required that the new object was of a different class.  This
required a hideous battery of external coroutines as well as copying
verbs and properties onto the object at runtime, since chparenting the
object would wipe out most of the information needed to complete the
transition.

In an MI system, this could have been easily implemented *in a generic
fashion* using the following class lattice:


	        Root class
               /          \
             ...          ...
             /              \
        Parent class #1   Generic Morphing Object
            |                |
            |                |
            |             Generic Morphing Turnip
            |                |
            \                /
             \              /
            Morphing Turnip 42


During the morph, the parent class #1 branch *only* is chparented to
parent class #2.  The information and code needed to perform the
transition is inherited from the Generic Morphing Turnip class, hence
safe from chparent().

You can do OO programming without an OO language.  The question is: do
you *want* to?

	-hpa

-- 
PGP public key available - finger hpa@zytor.com
"The earth is but one country, and mankind its citizens."  --  Bahá'u'lláh
"One net to rule them all, one net to find them, one net to bring them all
and using Unix bind them."  -- Alan V. Shackelford
References:
Home | Subject Index | Thread Index