Multiple base classes in .NET

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

Paul Werkowitz <newsgroups@primaprogramm.de> spake the secret code
<1fd4e049y61vc$.i7k81e3krf13$.dlg@40tude.net> thusly:

>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.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>

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

On Wed, 18 Jul 2007 01:41:56 -0700, Paul Werkowitz
<newsgroups@primaprogramm.de> wrote:

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

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

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

"Mark Rae [MVP]" <mark@markNOSPAMrae.net> wrote
> "Larry Smith" <no_spam@_nospam.com> wrote 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's very frequently used, and is a very powerfull tool to have access to.

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

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

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

"Mark Rae [MVP]" <mark@markNOSPAMrae.net> wrote
> "Larry Smith" <no_spam@_nospam.com> wrote 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's very frequently used, and is a very powerfull tool to have access to.

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

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

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

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

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

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

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

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

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.

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

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

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

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.

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

"Larry Smith" <no_spam@_nospam.com> spake the secret code
<uQGcOrZyHHA.484@TK2MSFTNGP06.phx.gbl> thusly:

>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.)
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>

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

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

"Larry Smith" <no_spam@_nospam.com> spake the secret code
<uQGcOrZyHHA.484@TK2MSFTNGP06.phx.gbl> thusly:

>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.)
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>

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