[Prev][Next][Index][Thread]
Re: MI: why?
On Wed, Jan 12, 2000 16:45 Uhr, jt <mailto:gkt37@dial.pipex.com> wrote:
>>
>> > As for Smalltalk, single inheritance is just flat out a mistake in
>> > language design. (If you disagree, don't bother trying to convince me,
>> > because you won't create even the tiniest bit of doubt in my mind.) I
>> > cannot stand the thought of learning another of those SI class
libraries
>> > with an outrageously deep hierarchy with functionality pushed up into
>> > totally counterintuitive classes in order to get it where it can be
>> > shared. A well-designed MI-based framework/library is so much easier
to
>> > understand and extend than an SI one.
>>
>> I agree 100%.
>
>Now this is interesting. I try to learn by other's mistakes and from
other's
>advice, and I have heard a lot of condemnation of multiple inheritance.
>Consequently I have carefully avoided it when it is present (C++ - may it
rot) and
>not missed it when it isn't there (delphi - but then delphi is primarily
used by me
>as a database front end, so it's a bit irrelevant). I don't condemn MI and
I would
>rather a language provided it, so I could ignore it, rather than be denied
it by
>someone else's choice.
>
>I can imagine rare cases where it might be valuable but I haven't
personally come
>across them yet. I am wondering if MI from purely abstract base classes is
at all
>bad. I don't like the feel of MI from non-abstract base classes - it
doesn't feel
>right.
>
>Please tell me more about why MI is good/bad/misused/whatever. I feel that
I may be
>missing out on a valuable facility.
>
>thanks
>
>jt
What MI is in C++
- putting the memory layout of the base classes behind each other im memory
to obtain a new memory layout for the derived class. Spice it up with some
syntactical sugar and vtable pointers and you are ready. This is a very
simple-minded approach to MI and C++ exploits all it can get
What MI is in Dylan (CLOS or whatsoever)
- MI means combining the _functionality_ of the superclasses. If a function
foo is defined on instances of class A then it is defined on instances of a
class derived from A because the latter inherits all the functionality from
the former. Since functionality does not sum up like the byte-count (foo =
foo + foo != 2 * foo, but foo < foo + bar > bar), you do not run into the
problems C++ has: no duplicate slots with the same names, need for
disambiguation, virtual bases etc.
In Dylan MI simply works. That's why programmers often factor out
functionality into mixin classes that can be incorporated into (almost)
every class by multiple inheritance. Almost, because the user can disable
it. In C++ the user has to allow it far up in the class hierarchy to be
able to use it, and it can still be painful sometimes.
Gabor
Follow-Ups: