# [MC] Multiple Inhertiance

Christopher Unkel (cunkel@us.itd.umich.edu)
Wed, 10 Apr 1996 18:08:39 PDT

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

    On Wed, 10 Apr 1996, Matthew Sanderson wrote:

    > He said 'parent', not 'ancestor'. There is no need to select which
    > _parent's_ verb you are going to pass() to if there's only one parent.
    > With arbitrarily many parents pass()ing introduces a real problem: if
    > several parents define a verb with the same name (a very likely scenario),
    > which one do you pick?
    > The point stands.

    C++ uses the scoping operator for this We could do the same thing here --
    if a verb wants to pass() to a specific ancestral version of itself it
    would specify obj::(verb)()... which would generate an error if obj was
    not an ancestor of the object, or verb was not the same as the verb running.
    Calling in this manner would preserve the usual things that pass() does
    -- specifically, the value of "this".

    > Relying on the order of objects in .parents for this choice seems to me to
    > be extremely iffy...

    The real problem is that it's not flexible enough.  What happens if I want
    most of the functions from one inheritance tree, and some from another?
    If pass() functions the same way as normal verb calls, I have, as you
    point out, no way to get at the other versions; I can't even write a
    version on the descendant that just pass()es to the version I want...

    Or, consider the version of multiple inheritance I propose a couple
    messages ago -- where ambiguity is simply not allowed.

    > Also: I don't see why you think chparent() becomes obsolete under a
    > multiple-inheritance server. This would mean that if my generic foo has
    > parents A, B, C, ... Z and I want to make it only a parent of BAZ (perhaps
    > I'm recycling it), I would have to remove_parent each of the 26 parents,
    > then add_parent BAZ. Ick.
    > chparent( {[parent, [parent, ...]]} ) would seem much more intuitive and
    > efficient to me...

    But a chparent() call like that would effectively have to do
    remove_parent for those not in the new list, and add_parent for those not
    in the list -- so it's no more *efficient*.  It's just more convenient,
    and as such, it's more fit for $ancestry_utils.

      --Chris                           cunkel@engin.umich.edu
        ResComp Network Support Technician, Bursley Hall
        "Invisibility is in the eye of the beholder."
        Home Page: http://www-personal.engin.umich.edu/~cunkel/