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.Bases" 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.Bases.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.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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.

I belive so.

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.Bases.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.

If is is arbitrary code, then I belive that you should be using
Type BaseType.

And it is obvious that it will only return one type.

Arne

 

[Jesse Houwing]

* Larry Smith wrote, On 14-7-2007 1:49:

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.Bases" 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.Bases.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.

The Visual Studio Extensibility model also supports non-CLR languages
(native C++ for example), so it has support for multiple inheritance.

The .NET types do not support multiple inheritance as you've already
found out. I've read a couple of rumors that multiple inheritance will
probably find its way back into the CLR in a future version...

Jesse

 

[Larry Smith]

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

I belive so.


If is is arbitrary code, then I belive that you should be using
Type BaseType.

Thanks for the tip. It might prove useful later but for the moment I might
not be able to retrieve the "Type" (since my app processes raw source files
before they may have even been compiled yet).

 

[Larry Smith]

The Visual Studio Extensibility model also supports non-CLR languages

(native C++ for example), so it has support for multiple inheritance.

The .NET types do not support multiple inheritance as you've already found
out. I've read a couple of rumors that multiple inheritance will probably
find its way back into the CLR in a future version...

Thanks for the clarification (appreciated). As for the rumour, I'm not sure
how they'll tackle that given that there already seem to be some built-in
assumptions based on single-inheritance. They could change this of course
but it might cause a lot of problems. Anyway, thanks again.

 

[Mark Rae [MVP]]

Thanks for the clarification (appreciated). As for the rumour, I'm not
sure how they'll tackle that given that there already seem to be some
built-in assumptions based on single-inheritance. They could change this
of course but it might cause a lot of problems. Anyway, thanks again.

I'd be surprised if we ever see multiple inheritance in C#...

http://blogs.msdn.com/csharpfaq/archive/2004/03/07/85562.aspx
http://www.google.co.uk/search?hl=en&rlz=1T4GGIH_en-GBGB220GB220&q="c#"+multiple+inheritance&meta=

 

[Larry Smith]

I'd be surprised if we ever see multiple inheritance in C#...

http://blogs.msdn.com/csharpfaq/archive/2004/03/07/85562.aspx
http://www.google.co.uk/search?hl=en&rlz=1T4GGIH_en-GBGB220GB220&q="c#"+multiple+inheritance&meta=

I'd be surpised as well. It's not likely to take off given that it's already
established as single inheritance. Moreover, it's rarely even used in the
C++ world. From my own (long) experience in that arena, it makes sense
conceptually but in practice it's mechanically very difficult to work with.
I doubt significant improvements can be made on this front.

 

[Mark Rae [MVP]]

I'd be surpised as well. It's not likely to take off given that it's
already established as single inheritance. Moreover, it's rarely even used
in the C++ world. From my own (long) experience in that arena, it makes
sense conceptually but in practice it's mechanically very difficult to
work with. I doubt significant improvements can be made on this front.

Indeed. I've been using C# since the latter half of 2002 and have never had
any need for multiple inheritance...

 

[Peter Duniho]

(removed microsoft.public.vstudio.extensibility and
microsoft.public.dotnet.framework.clr due to lack of relevance and
reduction of cross-posting)

I'd be surpised as well. It's not likely to take off given that it's
already
established as single inheritance. Moreover, it's rarely even used in the
C++ world. From my own (long) experience in that arena, it makes sense
conceptually but in practice it's mechanically very difficult to work
with.
I doubt significant improvements can be made on this front.

IMHO, C# already does make an improvement over multiple inheritance vs
C++. That is, a class can in fact inherit multiple interfaces. This
allows for the same basic behavior as multiple inheritance, while forcing
the programmer to be explicit about how the class is arranged (ambiguity
in behavior of base classes shared by multiply inherited classes being one
of the bigger stumbling blocks for multiple inheritance in C++, IMHO).

Pete

 

[Paul Werkowitz]

Am Sat, 14 Jul 2007 16:37:06 +0100 schrieb Mark Rae [MVP]:

Indeed. I've been using C# since the latter half of 2002 and have never had
any need for multiple inheritance...

Hello, how then can you advise me to implement the following:

I have derivations from the standard WinForm Controls that implement
certain protocols for loading, storing, verification etc. Code example:

//-----------------------------------------------------------------
// boBindName
//
[
Bindable (true)
, Category ("QFC")
, Description ("Feld/Property, an das gebunden werden soll")
]
public string boBindName
{
get { return mBoBindName; }
set { mBoBindName = value; }
}

I have many of those.

At the moment, I need to have the exact same code in all of my derived
controls. Any change in that code must be manually repeated for all
controls - a perfect situation for implementation inheritance with the help
of MI.

Paule

 

[Paul Werkowitz]

Am Sat, 14 Jul 2007 09:59:39 -0700 schrieb Peter Duniho:

IMHO, C# already does make an improvement over multiple inheritance vs
C++. That is, a class can in fact inherit multiple interfaces.

A class can implement multiple interfaces - roughly the same as in C++
(minor differences ignored). But a class in C# cannot use implementation
inheritance, which can be very useful. You have to duplicate the code, use
delegation etc.

This
allows for the same basic behavior as multiple inheritance, while forcing
the programmer to be explicit about how the class is arranged (ambiguity
in behavior of base classes shared by multiply inherited classes being one
of the bigger stumbling blocks for multiple inheritance in C++, IMHO).

No, disagree. The same ambiguity problems can arise when you implement
multiple interfaces in a C#-class. The solution is the same, though:
Compiler gives notice, and you have to manually resolve the amiguity,
usually by qualifying the name. No problem.

Paule

 

[Richard]

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

Paul Werkowitz <[email protected]> spake the secret code

Am Sat, 14 Jul 2007 16:37:06 +0100 schrieb Mark Rae [MVP]:

Indeed. I've been using C# since the latter half of 2002 and have never had
any need for multiple inheritance...

Hello, how then can you advise me to implement the following:

I have derivations from the standard WinForm Controls that implement
certain protocols for loading, storing, verification etc. Code example:

//-----------------------------------------------------------------
// boBindName
//
[
Bindable (true)
, Category ("QFC")
, Description ("Feld/Property, an das gebunden werden soll")
]
public string boBindName
{
get { return mBoBindName; }
set { mBoBindName = value; }
}

I have many of those.

At the moment, I need to have the exact same code in all of my derived
controls. Any change in that code must be manually repeated for all
controls - a perfect situation for implementation inheritance with the help
of MI.

Personally, I'd question any design that is encouraging you to
subclass every .NET WinForms Control.

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:

class BindableControl<T> : T
{
[Bindable(true)]
[Category("QFC")]
[Description("...")]
public string boBindName
{
get { return mBoBindName; }
set { mBoBindName = value; }
}
private string mBoBindName;
}

This eliminates the duplication, but it still is requiring you to
subclass every .NET control. I'd consider other design alternatives
that wouldn't require you to do this.

 

[Peter Duniho]

A class can implement multiple interfaces - roughly the same as in C++
(minor differences ignored). But a class in C# cannot use implementation
inheritance, which can be very useful. You have to duplicate the code,
use
delegation etc.

I prefer to use the term "composition". But whatever. Whether you call
it "delegation" or "composition", it works fine.

No, disagree.

Then you do so incorrectly.

The same ambiguity problems can arise when you implement
multiple interfaces in a C#-class.

If you think "the same ambiguity problems can arise", then you don't
understand which ambiguity problems I'm talking about.

I am specifically speaking about the problems that arise when a single
class implicitly inherits the same implementation from the same base class
multiple times. This simply does not happen in .NET, because you can only
inherit implementation from any given class once.

In any case, I do not intend to rehash to ridiculous thread that already
occurred in the C# newsgroup about MI. If you think that the lack of MI
in .NET and/or C# is a fundamental flaw, then don't use .NET and/or C#.
Simple as that. If you don't believe it's a fundamental flaw, then get
over it and quit wasting time complaining about the lack of it. There are
workarounds that work fine for people who can get over their love affair
with MI.

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
pitfalls that true MI creates.

Pete

 

[Chris Mullins [MVP]]

"Larry Smith" <no_spam@_nospam.com> wrote in message

[Multiple Inheritence]

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's very frequently used, and is a very powerfull tool to have access to.

My experience is otherwise. I've used it alot, loved it, had great success
with it, and really miss it.

Indeed. I've been using C# since the latter half of 2002 and have never
had any need for multiple inheritance...

I've been using the C# since 2001 (neh! heheh. ) and have had many, many
cases where multiple inheritence would have been the correct answer. Without
MI, I've been stuck jumping through crazy Interface hoops, duplicating all
sorts of implementation logic, and generally been forced to take a very
powerfull tool out of my bag of tricks.

I know there are no changes planned on this front, and as a result, I'm
beating a dead horse, but I find it quite frustrating. I continually hear
people say, "I don't use it, have never used it, and will never use it -
therefore it's not needed.".

 

[Daniel Marohn]

My experience is otherwise. I've used it alot, loved it, had great success

with it, and really miss it.

I agree (cannot say how much!)

 

[Larry Smith]

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

That's just... not right.

Actually it is. I've worked for many different companies both large and
small and almost nobody uses it. I find it very hard to believe this isn't
the norm.

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).

Actually it's not full of MI. There's precious little of it in fact. The
streams library is really all that there is and its MI model is very simple.
If something else exists that uses MI then it escapes me right now as I've
been immersed in C# for the last 18 months now (after many years in C/C++).
There's nevertheless a big difference between using the STL classes and
applying MI in your own code. You normally don't get your hands dirty with
it at this level. In fact, from a programmer's perspective it really
functions as SI for all intents and purposes. That is, you normally don't
deal with the complicatd issues that can make MI difficult to deal with.

It's very frequently used, and is a very powerfull tool to have access to.

I didn't say it wasn't powerful. The mechanics get progressively more
difficult to work with however as class hiearchies become non-trivial.

My experience is otherwise. I've used it alot, loved it, had great success
with it, and really miss it.

You must have precious little experience dealing with large class
hierarchies then.. When you factor in issues like virtual base classes, the
calling of their constructors from the most dervied class (which refutes
your claim that MI is widely used since very few C++ programmers even know
about this), the headaches involved with ambiguity (a major pain), etc.,
then it becomes a major deterrent very quickly unless your class hierarchies
remain trivial.

I've been using the C# since 2001 (neh! heheh. ) and have had many, many
cases where multiple inheritence would have been the correct answer.
Without MI, I've been stuck jumping through crazy Interface hoops,
duplicating all sorts of implementation logic, and generally been forced
to take a very powerfull tool out of my bag of tricks.

I know there are no changes planned on this front, and as a result, I'm
beating a dead horse, but I find it quite frustrating. I continually hear
people say, "I don't use it, have never used it, and will never use it -
therefore it's not needed.".

The lack of MI has caused problems for me as well on occasion. You don't
need to duplicate interface logic however but that's another story. In fact.
I firmly believe that MI is conceptually superior to C# interfaces since
it's a more natural model of objects in the real world. It's mechanically
difficult (even challenging) to work with however once you start
encountering the problems in my previous point. This is my only real beef
with it.

 

[Richard]

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

"Larry Smith" <no_spam@_nospam.com> spake the secret code

Actually it's not full of MI. There's precious little of it in fact. The
streams library is really all that there is and its MI model is very simple.

One library I've seen that uses MI all over the place is ATL, but in
that case the MI is used to aggregate various bits of COM behavior.

You must have precious little experience dealing with large class
hierarchies then.. When you factor in issues like virtual base classes, the
calling of their constructors from the most dervied class (which refutes
your claim that MI is widely used since very few C++ programmers even know
about this), the headaches involved with ambiguity (a major pain), etc.,
then it becomes a major deterrent very quickly unless your class hierarchies
remain trivial.

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.)

 

[Larry Smith]

One library I've seen that uses MI all over the place is ATL, but in
that case the MI is used to aggregate various bits of COM behavior.


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.)

I'm very familiar with this book having read it in nauseating detail once
upon a time (it's really the bible of ATL). ATL is brutally difficult
however. It took me a long time to master it and I have many years of C++
experience. For the less experienced it's downright dangerous. Hardly a good
example of MI nor many other techniques (for C++ experts only).

 

[Richard]

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

"Larry Smith" <no_spam@_nospam.com> spake the secret code

[...] Hardly a good
example of MI nor many other techniques (for C++ experts only).

Its just the only library I can think of that uses multiple
inheritance heavily.

Other than that, I can't think of a typical Windows library that uses
multiple inheritance heavily like that.

 

[Ben Voigt [C++ MVP]]

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.

{
[Bindable(true)]
[Category("QFC")]
[Description("...")]
public string boBindName
{
get { return mBoBindName; }
set { mBoBindName = value; }
}
private string mBoBindName;
}

This eliminates the duplication, but it still is requiring you to

Except it doesn't work.