# Multiple Inheritance [longish]

Michel Lavondes (lavondes@tidtest.total.fr)
Mon, 17 Feb 1997 05:30:23 PST

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    In message <3305ED78.1C35@mv.mv.com>, Chris Williams writes:
    > Has anybody experimented with in-DB multiple inheritance?

    IMO there are two valid uses for multiple inheritance :

    1- self-contained classes that you have no good reason to connect at
    any single place in the inheritance tree, but whose functionality you
    might want in several places (feature-ish classes)

    2- classes that have a genuine need to borrow code or properties from
    several potential ancestors (some of which may be feature-ish classes
    as described in 1)

    I personally believe in making multiple inheritance explicit, as any
    kind of inheritance rules frozen in language specs will either not
    suit anyone's beliefs about the way it should work (except maybe its
    implementer's), or attempt to do so and in the process become a hairy
    mess (how many of you who program in C++ regularly can write down in
    less than 1 hour all the rules about or involving inheritance, without
    opening the ARM or the latest ANSI draft standard ?).

    I have personally never done this in MOO, but I remember having done
    similar things in Smalltalk some years back (Smalltalk also has single
    inheritance). AFAIR, I implemented it in the following way :

    - Feature-ish classes hang either directly below #1 or below a close
    descendant (eg, $thing).

    - Classes that need to hang from several points in the inheritance tree
    are separated into a call core (feature-ish, contains properties and
    verbs specific to the class) and one glue class for each point of
    attachment in the IT.

    - The glue class is responsible for calling the feature-ish core and
    the ancestor. Each instance of the glue class has an instance of the
    feature-ish core as a property.

    - For simulating multiple inheritance, I do similar things, except that
    the glue class has one property for each "simulated" ancestor and hangs
    near the root. It calls the core (or doesn't, since in that case it and
    the core may be merged) and calls the right verb on the right "ancestor"
    as needed to achieve the desired "inheritance".

    True, this requires a lot of glue code, but it may possible to abstract
    it in a way similar to what #3:huh works, maybe through a multiple-
    inheritance-root class, with its own :huh.

    Just my $.02

    Michel Lavondes (lavondes@tidtest.total.fr), speaking only for himself

    "Yea, the heavens shall open and the NP-complete solution be given forth.
    ATT executives shall give birth to two-headed operating systems, and
    copyrights shall be expunged. The voice of the GNU shall be heard, but
    the faithless will be without transceivers." -- Steve Simmons