2

Yes I was asked this question and all I could provide, was a summary of following info that I knew. Ofcourse other than getting the error when writing the so-called expected code, wish we could write 1, could there be more valid reasons to prove that C# doesn't support Multiple Inheritance?

Many questions asked here in SO and outside web in the context of MI of C#, comparing C# to Java (where Java implements MI with interfaces), how to simulate/emulate MI in C#, How to deal with lack of MI in C#, what is the problem with MI etc.. So my question may reflect bits of duplicity to those questions...however I haven't found the answer yet, hence thought of shooting.

In a blog I saw the author is talking about some valuable points:

  1. Different implementations of MI across languages makes it a challenge to make a language-neutral implementation.
  2. Interfaces can be used instead, which makes MI a bit redundant.
  3. MI adds complexity in regards to casting, reflection and so on.

Author indicates that Multiple inheritance of implementation is what not allowed in C#. So to stop leading to a double diamond inheritance problem/deadly diamond of death.. Like author had pointed out saying "I have inherited a lot from both my mother and father"..

So it makes more sense for a Class to inherit from multiple super/base/parent classes. E.g. Class House inherits from Class Building (the noun, represents details of a building{house, school, office, hotel etc}) and Class Construction (represents details of construction a building). Thus it would be great if we could, 

1. code wish we could write
public class House: Building, Construction {
// methods, properties...
}

Instead we have to write that interFACE.. 

interface Buildstruction
{
    methodConstruction();
}
//class Construction then has to implement the interface

public class  House: Building, Buildstruction
{
    Construction ConstionObject;
    methodBuilding();
    methodConstruction() { ConstionObject.methodConstruction(); }
}

Wouldn't it had been easier to not allow multiple super classes to have the same name methods (e.g. calculate method)? Then I realize those parent/super classes need to have the freedom to create their own properties and methods independent of another class..

Thus MI seems mission impossible in C#...and what reasons determined why it is so.. Is it merely because of,

  • The diamond problem?
  • And no-body has yet really pointed out the real use of MI in programming?

Also how does,

  • MI add complexity in regards to casting, reflection?
  • Interfaces make MI a bit redundant?
  • MI cause issues for a code (full OOP supported) to be language independent?

Appreciate a comment/an answer that says more than just "it's the way C# language is created..." :)

Community
  • 1
  • 1
bonCodigo
  • 14,268
  • 1
  • 48
  • 91
  • possible duplicate of [How did C#'s lack of multiple inheritance lead to the need for interfaces?](http://stackoverflow.com/questions/14482483/how-did-cs-lack-of-multiple-inheritance-lead-to-the-need-for-interfaces) – Petr Abdulin Feb 11 '13 at 08:41
  • 2
    minus 2, seems a little hars. This is a fair question, and I dont think the answer is all that intuitive. Also - a good deal of research has already done, before asking. – Jens Kloster Feb 11 '13 at 08:44
  • Those who mark the question to be closed: please notice that I have 4 questions here: Is C# not supporting MI, merely because of, `1.` The diamond problem? And no-body has yet really pointed out the real use of MI in programming? `2.` How does MI add complexity in regards to casting, reflection? `3.` How does Interfaces make MI a bit redundant? `4.` How does MI cause issues for a code (full OOP supported) to be language independent? – bonCodigo Feb 11 '13 at 08:44
  • @PetrAbdulin well as you can see in my question it self I have stated that some bits *may look* duplicates, but it's not. If I could find the answer using the posts/questions in SO so far, I wouldn't post my question. So it's not a duplicate to what you say. But I found some interesting info in it already. To say the **issues cause using `interfaces`** as a solution for `MI`. – bonCodigo Feb 11 '13 at 08:52
  • 1
    The main question here is why it's determined so. I guess that's a fair question. Anders is the guy that designed C# as well as a couple of other languages. I think your question is fair, and there's definitely a lot of speculation going on, so I'll do my best to answer it. Anders once said about Delphi that he didn't put it in because it would slow down the speed of the compiler. This reason makes a lot of sense. As for the use: MI has a lot of real uses, to name one: in C++ people use type lists to make 'compiler assertions'. Type lists are impossible without MI. – atlaste Feb 11 '13 at 08:55
  • @StefandeBruijn thank you. Yes I have 4 questions and one is the valid determining reasons. The other three are as much important as the 1st. However I believe if answer for question one can be expanded to cover each of those 3 questions, then that's perfect. e.g. MI adds complexity in terms of casting/reflection. That could be a reason to avoid MI. But can someone explain the problem with an example of how `casting` is an issue with MI? So on.. – bonCodigo Feb 11 '13 at 09:02
  • Well my point was that it's more difficult to create a compiler: For an interface, you just need the signatures and there can never be a conflict, when doing MI, you must check for conflicts and overload resolution gets more difficult, f.ex. when dealing with diamonds. MI has nothing to do with language independence, reflection, etc... it's just a choice they made when designing .NET. I'm sure solutions for reflection here can be found. Interfaces also don't make it redundant (ref. typelists). I don't even think it has to do with stupid developers that want protection from difficult code. – atlaste Feb 11 '13 at 09:19
  • @StefandeBruijn: MI issues go far beyond the compiler. Given X:B, Y:B, and Z:X,Y, do the X and Y in a Z share a B, or each have their own? If not, it will be hard for them to maintain invariants that don't get stomped on by each other. If each has its own, then (B)(X)someZ and (B)(Y)someZ must be distinct, which would disallow constructs like (B)(Object)someZ, which .NET assumes should be work with any class type derived from B. – supercat Dec 17 '13 at 22:14
  • @supercat Sure, not having diamonds isn't really a practical option for .NET like languages. Having diamonds introduces a lot of compiler complexity. – atlaste Dec 18 '13 at 09:10
  • @StefandeBruijn: The difficulty isn't in writing a compiler, but rather specifying *what it should do*. Given `string CompareThreeThings(object a, object b, object c) { return String.Format("{0} {1} {2}", a==b, b==c, a==c);}`, what should `CompareThreeThings((X)someZ,(Y)someZ,someZ)` return? No matter how skilled a compiler writer may be, there's no combination of behaviors it could implement without violating some .NET axioms of reference-types behavior which are more useful than generalized MI would be. – supercat Dec 18 '13 at 17:10
  • @supercat False? :-) Sure, but I was just quoting - let's face it, it's not up to you or me. Still, I've googled for the exact quote, but can't find it anymore... either way, I think the top answer here is the best answer that tells why it's currently not supported: http://stackoverflow.com/questions/2761733/why-does-vb-net-not-support-multiple-inheritance . – atlaste Dec 19 '13 at 09:35

0 Answers0