Multiple Inheritance in .NET

I have been noticing several blog posts on the omission of Multiple Inheritance in .NET such as Stan Lippman's post on MI Efficiency and Fran Bouma's post.

One complaining developer refers to the tedious task of reproducing the exact same code for each class derived from same interfaces--not to mention the maintenance drudgery of replicating any later change made to one class to all other classes.

I see many problems with supporting MI in .NET. Currently, object references to the same object in .NET always refer to same pointer value (modulo garbage collection) regardless of the type that the reference is being interpreted as. This constraint would likely go away, if MI was introduced. Some of the benefits of fixed object references include the following:

1) Array covariance, the ability to reinterpret an array of a certain type as an array of a base type.
2) Optimal performance for most reference operations -- equality tests, method call invocations, etc.

Interfaces resolve most of the issues MI is used for. However, interface methods perform significantly slower than regular methods.

1) Interface method access requires 3 indirections in .NET v1.1, where as a regular virtual method requires just 1 indirection. Keep in mind, a non-virtual function is a direct call with no indirections and may actually be inlined.
2) Interface casting is also more expensive the regular object casting.

Simulating MI is possible as the Eiffel.Net developers have reimplemented Multiple Inheritance in managed code. This Eiffel compiler defines a corresponding interface for each class with the same methods and redundantly generates the same implementation for each class derived from the same interface. Unfortunately, this is a least common denominator approach, forcing objects to incur the performance inefficiencies of using interfaces.

Reportedly, the CLR team is looking into supporting default implementations for interfaces methods. That, I believe, would resolve many of the complaints toward the CLR levied by MI enthusiasts. One can actually emulate default implementations today in a less elegant fashion by constructing a helper class consisting of static methods, each having an interface object as the first parameter.

Anders Hejlsberg indicated during a PDC panel that, while MI support is not planned for a future version of .NET, the CLR team is looking at supporting mix-ins, which is a type of MI based on generics. Mix-ins provide a kind of implementation inheritance that interfaces currently lack.

Support for MI would likely complicate the runtime, leading to reduced performance and numerous restrictions on the ability to use objects, especially in areas dealing with object covariance and contravariance. In combination with generics, we may actually lose the code sharing that occurs with generic types based on reference types. In addition, I think the presence of MI might actually pollute the library. I think it's best to try explore other options first.

Comments

[Vijay]

Thanks for the information on how Eiffel implements MI ! I didn't know these details ! pretty interesting :)

[Maxim V. Karpov]

I just ran into good senario for using MI.

I needed to developed a Typed collection and inherit from a System.ComponentModel.Component. I can not iherit from System.ComponentModel.Component and ystem.Collections.CollectionBase. So I had to implement IList interface and code ArrayList undernith. It is aways of time.

On the other hand I understand the CLR complication by MI.

Maxim