Survey Results

Andrew Torrance18-Mar-02 0:04

18-Mar-02 0:04

Because you need information about the inheritance tree in order to make sure it works . Such information is not always available , and can be a real bugger to debug if and when MI eventually kicks you in the ass. If you have complete control of all source in a project then there is a case to use it .(I'm ignoring pure virtual base classes used as interfaces, where it is useful and safe ). However if you have complete control , then why not design so that MI is not needed and hence make debugging easier for those who come later ?

Re: Why avoid it?

Tom Archer20-Mar-02 5:17

Tom Archer

20-Mar-02 5:17

There are a lot of ideosyncracies about MI that can make it difficult to use and maintain. Since I have about 12 years or so of C++, I have used MI quite a bit. However, I only use it for my own personal projects. In situations where I'm consulting or programming for someone else where I don't know who will eventually maintain the code, then I shy away.

By the way, you'll notice that the C# design team intentionally left this feature out (as did the Java team I believe).

Cheers,
Tom Archer
Author, Inside C#

Re: Why avoid it?

Joaquín M López Muñoz21-Mar-02 12:04

Joaquín M López Muñoz

21-Mar-02 12:04

I don't mean to begin a flame war here, but... Suppose in a high-level design you come with some C tha IS-A A and a C. If you're programming for someone else, would you prefer explaining to her about the standard artifact in Java/C# for dealing with such situation (namely derive from an interface and delegate to a private member)? Is this more intuitive/maintainable than multiple derivation?
Seriously, MI is not such a common pattern, and can lead to obfuscated design, but when it is the appropriate thing to do it can save your life. It goes along with C++ philosophy of treating programmers as grown adults and let them have access to all the tools available, dangerous as they may be.
I know you're a C# guru, so I'd like to know whether there is a pragmatic reason for leaving MI out of this language. Does it make reflection or some other feature harder to implement? That could be a reasonable case against MI.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Re: Why avoid it?

Tom Archer22-Mar-02 7:19

Tom Archer

22-Mar-02 7:19

>>>
If you're programming for someone else, would you prefer explaining to her about the standard artifact in Java/C# for dealing with such situation (namely derive from an interface and delegate to a private member)?
<<<
Many times when I consult or program for someone, I'll never meet the people that will eventually maintain my code. Therefore, I take it as part of my responsibility to use techniques that are what I feel are standard. It's been my experience that MI is not something that the average programmer fully understands. You'll also note that people such as Bruce Eckel of the C++ standard committee shares this belief and also recommends against using it accept in very rare situations where there are no other options.

>>>
...but when it is the appropriate thing to do it can save your life. <<<
I agree

>>>
It goes along with C++ philosophy of treating programmers as grown adults and let them have access to all the tools available, dangerous as they may be.
<<<
This has nothing to do with treating people as adults and everything to do with the practical realities that part of my responsibility as a programmer is to turn in code that 1) gets the job done and 2) requires as little in terms of maintenance and learning as possible.

>>>
I know you're a C# guru, so I'd like to know whether there is a pragmatic reason for leaving MI out of this language. Does it make reflection or some other feature harder to implement? That could be a reasonable case against MI.
<<<
If you look closely at C# you'll see many situations where the language left out features that are C++ because the risk/reward ration was deemed to high. Case fallthrough is a perfect example of this. Most experienced developers are not going to commit an error with this and love having it at their disposal. However, as Eric Gunnerson explained to me, its not technically needed (as there are other ways to accomplish the same thing) and only serve to get less experienced programmers into trouble. Therefore, while you might very well be a highly-competent programmer who knows MI inside/out, the simple fact is that it gets too many developers into trouble to be worth its risk with its inclusion in the language.

Cheers,
Tom Archer
Author, Inside C#

Re: Why avoid it?

Matthew Adams23-Mar-02 7:44

Matthew Adams

23-Mar-02 7:44

I think that IS A is *always* a contentious design decision. BEHAVES LIKE A is (almost) always a more conservative and pragmatic analysis. You should work on the assumption that the latter is the case, and only solidify to an IS-A relationship if you prove, late in the design process that the relationship holds.

Matthew Adams
Development Manager
Digital Healthcare Ltd

It's all George's fault

Nish Nishant17-Mar-02 15:05

Nish Nishant

17-Mar-02 15:05

We were having nice simple polls like do you like the new VS.NET UI or how many of you like C# or some such nice simple stuff.

Now it's all templates and multiple inheritance.

And that Georgie Boy is not even to be seen.

Nish Wink | ;-)

My miniputt high is now 29
I do not think I can improve on that
My temperament won't hold

www.busterboy.org

Option	Votes	%
Yes, I often derive from multiple classes	135	13.80
Yes, I occasionally derive from multiple classes	376	38.45
Yes, I use classes that are derived from multiple classes (but don't create these classes myself)	90	9.20
No - I see no need	192	19.63
No - the language I use doesn't support MI	44	4.50
No - I intentionally avoid MI.	141	14.42
Total	978	100%

Multiple Inheritence [Edit]