[Prev][Next][Index][Thread]

# Re: MI

- Date: Sat, 11 May 1996 01:22:04 PDT
- From:
- Reply-To:
- Content-Transfer-Encoding: quoted-printable
- Content-Type: text/plain; charset=ISO-8859-1
- Newsgroups: local.moo
- Organization: Where Stormnet meets the Internet
- References: <Pine.LNX.3.92.960511021814.30579A-100000@phish.nether.net>

    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:

- MI

- From: <warp@phish.nether.net>

- Prev: MI
- Next: Minor security bug in $note_editor
- Index: MOO-cows
- Thread: MOO-cows

Home | Subject Index | Thread Index