On multiple inheritance

[Matthew Tuck]

Hans-Dieter Dreier wrote:

> That is what I would expect. It would mean that you couldn't compile a
> class without looking at its siblings and descendants, which would not
> be good for incremental compilation. Also, this is just a relief for
> the waste of space, not a cure. Anyway, it adds complexity which is
> not a good thing in itself.

At least some incremental compilation could be done, and again,
optimisation and incremental compilation can be a tradeoff.

As for the waste of space, it is merely one implementation scheme.

> Can you give an example?

I've seen an example where the weights of two components are added, but
I don't like this one since inheritance is meant for "is-a" not
"is-a-part-of" which adding the weights of subparts to get the total
weight is.  But that would be the sort of idea.  Basically you can
combine the clashing methods in common ways.  If that wasn't enough, you
could just override.

> The calls will be nested in some manner which is not obvious until you
> look at it in detail.

I don't see that.  Base class to subclass for constructors is pretty
intuitive, although it's not always exactly what you want.

> > Ok, I'm getting a little confused.  Would you be able to give a full
> > example of a Person, Customer, Employed and Employed Customers?  Then I
> > might be able to comment a bit further.
> ...
> pE would be the name of the parameter inside the class. And you could pass it on as a class
> parameter the same way you could do with every variable. The type of the parameter the caller
> passes in must be determinable at compile time, exactly like a function argument.

Don't you still need to store slots in memory for the main object even
if they delegate to a contained "superobject"?

>> Could you assign one to the other for example?
> No, I don't think so. It would have to be converted to a Person first by retrieving the
> parameter, which could be done by an automatic type conversion, but the Customer (or
> Employed) part would be lost. I admit, this might be a problem sometimes. But I suppose it's
> the price you have to pay in order to get the inheritance structured hierarchically.

Yeah.  I think the main purpose of inheritance is to achieve this sort
of thing.  Anyone can implement something like your proposal for single
inheritance, but you don't get the subtyping relationship which allows
you to assign one to the another.  Multiple inheritance aims to maintain
that.

> > ... separation of code inheritance from specification
> > inheritance, etc.
> 
> Can you explain that?

OK, well basically you have something like:

Type A --implements---> Implementation C
  |                       |
subtype(inherits spec)  subimpl(inherits code)
  v                       v
Type B --implements---> Implementation D

Thats the standard sort of subclass if you separate them into two
different relationships.  If you separate them out, you can get
intesting things like:

type A
type B extends A
type C extends B

impl Y implements A
impl Z implements C inherits Y

Notice how Z takes the specification of C, yet the code from A, which is
two types up rather than one.

I'll try to think of a more convincing example, I hope that was
understandable.

> It might also provide a "view" of a class where only the specification part is visible
> although the implementation is present as well. At any rate, I would like to avoid the
> overhead of having to declare the things specified by the specification a second time when it
> comes to implementing. That's exactly the sort of tedious work I always hated in C, and prone
> to typos as well. Maybe the editor can generate sort of a template where all those parts
> inherited from the specification would be noneditable.

Yes, in Ada you have to specify both the spec and the impl.  This really
annoyed me, and put me off spec/impl separation for a long time.  I came
back to it when I saw more advantages and solutions to the
disadvantages.

-- 
     Matthew Tuck - Software Developer & All-Round Nice Guy
                              ***
       Check out the Ultra programming language project!
              http://www.box.net.au/~matty/ultra/