Give back multiple inheritance

[sgrantham at sympatico.ca]

Mixins can help but are still verbose.  The main reason Java and C# don’t allow
multiple inheritance is because they (Java and C#) support late binding.  For
instance, suppose you had and abstract class called “Winged” that defined a
virtual method called “Fly” and you had two classes “Glider” and “Flapper”,
derived from “Winged”,  that each had their own implementation of method “Fly”.
Then if you created another class “FlyingMammals” that had multiple inheritance
from both “Glider” and “Flapper”, a reference to “Winged::Fly()” would be
un-resolvable at runtime because its ambiguous.  This is resolved with
"Interfaces" since they don't actually have an implementation of a particular
method so two different interfaces with the same method declaration still only
yields one implemenation.  The one in the containing class.

Having said all that I truly believe a compromise position is the order of the
day, but it requires a consolidation of what I see as a number of artifices in
languages when considered in programming abstractions.  There are several,
current, language concepts that are, to me, so intimately related that they
actually represent only one broader concept.  These are templates versus
abstract classes versus interfaces versus multiple inheritance and finally,
virtual base classes.

Instead of having all these different proto-class definitions, they can all be
collapsed into abstract classes with some extra refinement.  NOte that
Interfaces, which support multiple inheritance, are really just abstract classes
with no implmentation details.  So one need only add one additional rule to
class inheritance.  That is, "a real class can only have multiple inheritance
from abstract classes".  I.E. 

A real class may be derived from only one other real class. (The same as now.)

An abstract class may be derived from only one other real or abstract class.
(The same as now.)

A real class may be derived from one real class, but as many abstract classes as
one wants.  (This is the same as renaming "interfaces" to abstract classes and
allowing interfaces to have a default implementation.)

Abstract class derivation would be in the form of specifying inclusive lists and
exclusive lists.  Exclusive list would be bracketed.  For example:

class FlyingMammals extends Animal includes Mammal (Glider, Flapper) Arboreal
{
..
}



Then, the compiler needs to generate an "must override" error if a real class
definition attempts to inherit from multiple abstract classes that are in an
inclusive list and have any of the same public or protected member names (Or
"Required override on 'final'" if an override is blocked).  Any members, (both
properry and method), can be overridden in order to "disambiguate" the actual
implementation.  For example, if "Glider" and "Flapper" were inclusive then:

class FlyingMammals extends Animal includes Mammal Glider Flapper Arboreal
{
public void Fly()
{
if(typeof(this) != Winged || (typeof(this) == Winged && this.Tired &&
this.Airborne))
Glider::this.Fly();
else
Flapper::this.Fly();
}
}


You can then could collapes templates into this by having an abstract object
types and class abstract arguments to the class definition.  For example:

abstract class Vector( SomeType )
{
SomeType[] Elements;

..
}

Because all this is done through abstract classes, compiler implementation is
much easier in that it merely needs to build a vector table at compile time for
each of the inherited types, "union" the exlusive types and enforce overrides
for duplicate names.