Multiple base classes in .NET

[Larry Smith]

I just read a blurb in MSDN under the C++ "ref" keyword which states that:

"Under the CLR object model, only public single inheritance is supported".

Does this mean that no .NET class can ever support multiple inheritance. In
C++ for instance I noticed that the compiler flags an error if you use the
"ref" keyword on a class with multiple base classes. This supports the above
quote. However, under the "CodeClass2.Bas es" property (part the VS
extensibility model), it states that:

"Bases are super types of CodeElements. For Visual Basic and Visual C#
there is always only one element in the collection except when the code type
is a CodeInterface".

This is true of course since these languages only support single (class)
inheritance. However, it should be true for all .NET classes based on the
first quote above. My issue is therefore this. I want to retrieve the base
class of an arbitrary class in an arbitrary code file by invoking
"CodeClass2.Bas es.Item(1)". This works in my testing but will it always work
for all languages in theory, assuming the class I'm targetting is always a
..NET class of course. Thanks in advance.

[Ben Voigt [C++ MVP]]

On the other hand, ATL does all its business with template tricks and

doesn't use the virtual function call mechanism very much, if at all.
(I can't recall right now if it uses any virtual functions or not, but
my recollection is that I don't recall any virtual function business
going on when I last studied the ATL Internals book.)

LOL

COM is built on a function dispatch table... in C++ parlance, a v-table.

Now, the implementation might not call those virtual functions
polymorphically , but ATL projects are full of virtual functions.

[Ben Voigt [C++ MVP]]

The basic behaviors that MI allow still exist in .NET. They just require

writing a little more code, while at the same time avoiding some of the

"Just require writing a little more code" = increased maintenance burden.

pitfalls that true MI creates.

No, because all the pitfalls that MI creates are now left to the programmer
to handle manually (i.e. MI member lookup has compiler assist which might
have an ambiguity, in .NET the programmer must explicitly list which method
is being called. And the consumer is still faced with ambiguity, as stated
earlier.)

[Richard]

[Please do not mail me a copy of your followup]

"Ben Voigt [C++ MVP]" <rb*@nospam.nos pamspake the secret code
<uD************ **@TK2MSFTNGP05 .phx.gblthusly:

>MI is only one way to aggregate behaviors, not the only way. In .NET
you can implement multiple interfaces to aggregate multiple behaviors
into a single class. In .NET 2 you also have generics, so you can do
template type tricks:

Sorry, but generics aren't templates, and you can't "do template type
tricks".

>>
class BindableControl <T: T

For instance, that line won't work with generics.

Interesting! OK, I didn't know that.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.co m/~legalize/book/download/index.html>

Legalize Adulthood! <http://blogs.xmission. com/legalize/>

[Richard]

[Please do not mail me a copy of your followup]

"Ben Voigt [C++ MVP]" <rb*@nospam.nos pamspake the secret code
<#o************ *@TK2MSFTNGP02. phx.gblthusly:

>On the other hand, ATL does all its business with template tricks and
doesn't use the virtual function call mechanism very much, if at all.
(I can't recall right now if it uses any virtual functions or not, but
my recollection is that I don't recall any virtual function business
going on when I last studied the ATL Internals book.)

LOL

COM is built on a function dispatch table... in C++ parlance, a v-table.

COM, yes, but the mechanisms that ATL uses to implement itself are
built around templates and not virtual functions, IIRC.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.co m/~legalize/book/download/index.html>

Legalize Adulthood! <http://blogs.xmission. com/legalize/>

[Zachary Turner]

On Jul 18, 2:12 pm, "Chris Mullins [MVP]" <cmull...@yahoo .comwrote:

"Mark Rae [MVP]" <m...@markNOSPA Mrae.netwrote

"Larry Smith" <no_spam@_nospa m.comwrote in message

[Multiple Inheritence]

Moreover, it's rarely even used in the C++ world.

That's just... not right.

The entire STL is full of multiple inheritence. Every C++ programmer's first
program uses it, even if they're not aware of it (IOStream).

It certainly isn't "full of multiple inheritance". You gave one
example, and I don't think there's another. Multiple inheritance is
extremely unintuitive, hard to work with, and 99 times out of 100 it
is indicative of a bad design. 1 time out of 100 maybe you've got
something great with multiple inheritance, but one of the fundamental
philosophies of .NET is to err on the side of safety. Having been a C+
+ programmer for over 10 years, I'm praying multiple inheritance
doesn't ever see the light of day in .NET. Even single inheritance is
abused more often than not, when containment would be a much better
solution.

[Richard]

[Please do not mail me a copy of your followup]

"Chris Mullins [MVP]" <cm******@yahoo .comspake the secret code
<ul************ **@TK2MSFTNGP05 .phx.gblthusly:

>In all honesty, I've used [multiple inheritance] quite a bit,
and people I've worked with (many,
very hardcore OO purests) have also used it quite a bit. Does this mean
people may have overused it? Possibly. But this happens with every
technology.

So how do you feel about "Design Patterns" saying you should prefer
aggregation over inheritance?
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.co m/~legalize/book/download/index.html>

Legalize Adulthood! <http://blogs.xmission. com/legalize/>

[Chris Mullins [MVP]]

"Richard" <le************ *@mail.xmission .comwrote:

"Chris Mullins [MVP]" <cm******@yahoo .comspake the secret code

>>In all honesty, I've used [multiple inheritance] quite a bit,
and people I've worked with (many,
very hardcore OO purests) have also used it quite a bit. Does this mean
people may have overused it? Possibly. But this happens with every
technology.

So how do you feel about "Design Patterns" saying you should prefer
aggregation over inheritance?

I would feel alot better about aggregation if it were better supported by
the language.

If there was an attribute I could use:

[Aggregatable]
public class Point
{
int x; int y;
}

public class Circle
{
[Aggrigates(type =Single)] Point;
int Radius;
}

This code would:
1 - Automatically create an interface (IPoint) (or even an Anonymous Type)
2 - Automatically turn Circle into "Circle : IPoint"
3 - Automatically wire up "Circle.X" & "Circle.Y"

I would love to see a 1:Many aggrigation attribute as well:
public class VectorField
{
[Aggrigates(type =Collection)] Vector;
}

This would automatically:
1 - Turn VectorField into "VectorFiel d : IList<Vector>"
2 - Implement all the various IList<Vectorcod e for me

Even more fun would be:
public class TensorField
{
[Aggrigates(type =Dictionary<Vec tor>)] Tensor;
}

This would automatically:
1 - Turn TensorField into "TensorField:ID ictionary<Vecto r, Tensor>"
2 - Implement all the various IDictionary<Vec tor,Tensorcode for me

As it sits, aggregation (to me) means, "Write a whole lot of wrapper code to
wire up the various methods". In general though, in .Net I over-use
aggrigation simply becuase with single inheritence, there's no choice.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise , Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

[Richard]

[Please do not mail me a copy of your followup]

"Chris Mullins [MVP]" <cm******@yahoo .comspake the secret code
<u9************ **@TK2MSFTNGP03 .phx.gblthusly:

>"Richard" <le************ *@mail.xmission .comwrote:

>"Chris Mullins [MVP]" <cm******@yahoo .comspake the secret code

>>>In all honesty, I've used [multiple inheritance] quite a bit,
and people I've worked with (many,
very hardcore OO purests) have also used it quite a bit. Does this mean
people may have overused it? Possibly. But this happens with every
technology .

So how do you feel about "Design Patterns" saying you should prefer
aggregation over inheritance?

I would feel alot better about aggregation if it were better supported by
the language.

I think you missed the point of my question. Design Patterns was
written long before .NET was even an idea at Microsoft. DP isn't
about languages or syntactic sugar. In this case "prefer aggregation
over inheritance" is not saying never to use inheritance, nor is it
saying always use aggregation, but it is saying prefer one over the
other.

You seem to be expressing the exact opposite preference. DP goes
beyond issuing a simple aphorism and goes into the details of why
aggregation should be preferred over inheritance.

Beyond your simple personal preference, what are the reasons for
preferring multiple inheritance over single inheritance?

If even single inheritance is to be less preferred over aggregation,
then the case would seem to be even stronger against multiple
inheritance.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.co m/~legalize/book/download/index.html>

Legalize Adulthood! <http://blogs.xmission. com/legalize/>

[Chris Mullins [MVP]]

"Richard" <le************ *@mail.xmission .comwrote:

>
Beyond your simple personal preference, what are the reasons for
preferring multiple inheritance over single inheritance?

My reason is very simple:
Every now & then, I run across problems that are best solved though MI. This
seems to happen with about the same frequency I run across a problem that's
best solved by me creating a new thread. (e.g. every few weeks).

In the MI case, I can work around it. Interfaces & aggrigation allows for
this. It just means I have to write more code - sometimes a good deal more
code.

To me, the evolution of a platform means I write less code, especially for
common use cases. The less code that I write, the less likley that I am to
have bugs in my code.

If even single inheritance is to be less preferred over aggregation,
then the case would seem to be even stronger against multiple
inheritance.

I'm fine (and agree with!) with the argument for MI being "Perfer SI over
MI.".

That's a far cry from "Never use MI!", which is something I don't agree
with.

When I give presentations on concurrency, my logic is:
1 - Prefer Async Methods over anything else
2 - Prefer ThreadPool threads over custom threads.
3 - Prefer Timers & Background workers over custom threads.

.... at the very bottom of the list is, "If you really, really, must, go
ahead and create your own thread.".

This is a far cry from "Remove Custom Threads from the Platform!".

--
Chris Mullins, MCSD.NET, MCPD:Enterprise , Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

[Frank Hileman]

Hello,

Let me explain why I miss multiple inheritance.

Consider the following situation. Your class has a property X with a simple
field backing the property, with limited behavior -- all behavior is
independent of other properties. For design-time support you decorate this
property with several attributes, and add ShouldSerialize X and ResetX
methods.

Now to duplicate this property in another class, that has a different base
class (cannot share via inheritance) you must copy the field, all the code,
and the attributes. This is not a big deal with one property, but multiply
it by 20 or so properties and several classes, and you realize it is a
maintenance problem.

Interfaces don't help. An interface only helps when you need to use the
property, allowing you to avoid special casing for each class.

Delegation (aggregation) does not help either, because the code duplication
is at the surface level.

With mixin support in C#, we could create a mixin class for those
properties, and the code duplication is eliminated. If the mixin class does
not share any base classes with the "mixed" classes, there are none of the
usual diamond inheritance problems.

Consider scala's support for mixins as a good model for .net:
http://www.scala-lang.org/intro/mixin.html

Whether or not someone needs mixins depends on their task. Some domain
abstractions can be cleanly broken down into a strict hierarchy. Other
things are less hierarchical by nature and work poorly that way. So I don't
think anyone should claim no one needs mixins, or everyone needs mixins.

Personally I have needed mixins on a recent project and have wound up
pushing lots of members up the hierarchy, into base classes, when I would
prefer not to, just to avoid the pain of delegation.

Let me see if I can explain the motivation behind suggestion, "prefer
aggregation over inheritance". If you only use single inheritance, you are
limited by the type hierarchy. Additionally, multiple inheritance has
problems in some languages.

Those problems do not arise with good mixin support. Mixins can work better
than aggregation for code reuse, and mixin code reuse is not limited by the
type hierarchy. So "prefer aggregation over inheritance" is a reflection of
the languages used (probably c++).

Regards,
Frank Hileman

check out VG.net: http://www.vgdotnet.com
Animated vector graphics system
Integrated Visual Studio graphics editor

"Richard" <le************ *@mail.xmission .comwrote in message
news:Oo******** ******@TK2MSFTN GP03.phx.gbl...

[Please do not mail me a copy of your followup]

"Chris Mullins [MVP]" <cm******@yahoo .comspake the secret code
<u9************ **@TK2MSFTNGP03 .phx.gblthusly:

>>"Richard" <le************ *@mail.xmission .comwrote:

>>"Chris Mullins [MVP]" <cm******@yahoo .comspake the secret code
In all honesty, I've used [multiple inheritance] quite a bit,
and people I've worked with (many,
very hardcore OO purests) have also used it quite a bit. Does this mean
people may have overused it? Possibly. But this happens with every
technolog y.

So how do you feel about "Design Patterns" saying you should prefer
aggregation over inheritance?

I would feel alot better about aggregation if it were better supported by
the language.

I think you missed the point of my question. Design Patterns was
written long before .NET was even an idea at Microsoft. DP isn't
about languages or syntactic sugar. In this case "prefer aggregation
over inheritance" is not saying never to use inheritance, nor is it
saying always use aggregation, but it is saying prefer one over the
other.

You seem to be expressing the exact opposite preference. DP goes
beyond issuing a simple aphorism and goes into the details of why
aggregation should be preferred over inheritance.

Beyond your simple personal preference, what are the reasons for
preferring multiple inheritance over single inheritance?

If even single inheritance is to be less preferred over aggregation,
then the case would seem to be even stronger against multiple
inheritance.