From: doug@monet.ads.com (Doug Morgan)
Subject: Re: Novice? question: Designing for multiple inheritance w/ templates
Organization: Advanced Decision Systems, Mountain View, CA 94043, +1 (415)
	960-7300
	<1992Jul23.175814.15356@ucc.su.OZ.AU>
	<1992Jul25.065523.3855@uunet.uu.net!mole-end>
Date: Mon, 27 Jul 1992 19:38:31 GMT

In article <1992Jul25.065523.3855@uunet.uu.net!mole-end> mat@uunet.uu.net!mole-end writes:
>In article <1992Jul23.175814.15356@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>> In article <1992Jul21.131054.20622@mole-end> mat@mole-end writes:
> .
>  .
>   ....
>> 	When using mixins, the abstractions are derived, using
>> MI, from each other. They're the "problem domain" stuff aren't they?
>
>No, the examples you give are especially solution-domain.  They come from
>programming technology and express programming-type concepts applied to
>programmed objects.
>
>Problem-domain stuff includes most of the examples in the popular OO
>texts, things that are expressed as `is-a' or `is-a-kind-of-a,' e.g.
>`A hardcover book is a kind of a book' (derive hardcover book from
>book), `A salaried employee is a kind of employee,' (derive salaried
>employee from employee), `A gravel road is a kind of road,' (derive
>gravel road from road).

Multiple inheritance applies to all sorts of stuff, problem-domain and
implementation.  Inheritance essentially means adding new constraints
and extra behaviors (behaviors made reasonable because new constraints
are now guaranteed to be satisfied).  Multiple inheritance essentially
means taking the union of superclass constraints and behaviors (plus
any extras thrown in directly at the inheritance step).

Here is a simple problem-domain example:

                   book
                  /    \
      hardcover-book  book-with-color-plates
                  \    /
      hardcover-book-with-color-plates

Or another:

                 employee
                  /    \
   salaried-employee  handicapped-employee
                  \    /
        handicapped-salaried-employee

Or: gravel-less-than-2%-grade-road.

Note that none of the above problem-domain intermediate classes look
like (what I think most people would immediately call) a mixin.  They
all diamond back up to a common and fairly complicated class.  This
may be the root of issue in this thread.  Implementation-domain MI
often appears more mixin-like with multiple roots or with common roots
near the top of the class hierarchy.  Implementation-domain stuff
manipulates a hunk of memory and associated procedures.  In C++ no
class represents this concept, so implementation-domain MI could
easily have multiple roots.  In most other OO languages, some class
represents the high-level implementation aspects of all other classes
and implementation-domain mixins might inherit from that.  Another
view of the same argument: it wouldn't make much sense to make a
generic-thing-with-color-plates mixin.  Restricting the class to the
domain of books gives the class meaning.  So, problem-domain mixins
may tend to inherit from problem-domain classes rather than forming a
new root or inheriting strictly from a top-level class of the the
language.

>Is it possible to program with mixins for the problem domain?  Yes, it is.
>Is the result malleable?  I suspect not.  I haven't examined any large
>model built that way, so I'm not sure.  I rather suspect that some of the
>inheritance links that get built that way should be `part-of' links
>(bi-directional `has-a' links between objects collaborating to implement
>the functionality of the object representing the `whole').

Given good language support, MI and mixins are expressive and
malleable.  Given C++, your other implementation options might well be
worth exploring.

>-- 
> (This man's opinions are his own.)
> From mole-end				Mark Terribile
>
> uunet!mole-end!mat, Somewhere in Matawan, NJ

------------------------------------------------------------
Doug Morgan, doug@ads.com, (415) 960-7300
Advanced Decision Systems (a division of Booz-Allen & Hamilton Inc.)
1500 Plymouth St., Mountain View, CA 94043-1230
Newsgroups: comp.lang.c++