Timeline for Is there any "real" reason multiple inheritance is hated?
Current License: CC BY-SA 3.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 27, 2015 at 17:51 | comment | added | cHao | COM solved the problem by letting you ask the object itself for an interface that lets you manipulate it in a chosen manner. That "interface" may in fact be a full-fledged class, but you intentionally don't know or care about that. As for a "reference to anything" type, no, it's actually rather useless since generics. But you can have such a baseline type even with MI. | |
| May 27, 2015 at 17:34 | comment | added | supercat | @cHao: There are advantages to having a "reference to anything" type to which any reference may be cast in identity-preserving fashion. I think COM "solved" the problem by limiting its "inheritance" to the .NET interface pattern: don't allow a type to expose fields and require all methods be re-implemented by any implementing class. Does COM offer some other form of inheritance (multi- or otherwise) I don't know about? | |
| May 27, 2015 at 17:26 | comment | added | cHao | Casting in itself is just another hack to make strict static typing palatable. So i don't particularly care whether a cast is "identity preserving", because it's something that really ought to be avoided anyway. But the problem of switching from one type to another was already largely solved by the likes of COM, so there's no reason .net couldn't have done it as well. It already had to be done in order to make interfaces work in the first place. | |
| May 27, 2015 at 15:04 | comment | added | supercat | @cHao: If Moo:Zoo casts this to Object, should the result be the same as if Goo:Zoo does so, or if a Foo is cast directly? I don't think C++ would allow a direct cast from Foo to a multiply-inherited base type, but identity-preserving upcasts and downcasts are an essential and useful feature of Java and .NET. | |
| May 27, 2015 at 6:59 | comment | added | cHao | And that is exactly Foo must resolve the ambiguity between Moo::Zoo and Goo::Zoo: it's the only class capable of doing so. If there's no way to do that, then inheritance is not the right relationship. MI is less creating the problem than highlighting it as an actual problem. | |
| May 26, 2015 at 18:06 | comment | added | supercat | ...that would be very different semantics from a ((typeName)anythingElse) cast. | |
| May 26, 2015 at 18:05 | comment | added | supercat | @cHao: In an MI language, if Foo derives from Moo and Goo, each of which overrides a common inherited method Zoo in its own way, unless one inherited class is designated "primary", I'm not sure what base.Zoo could mean. Having a means for the derived class to invoke Moo's override of Zoo or Goo's override of Zoo would be fine, and one could define a syntax ((typeName)base).member which was only valid when typeName was either the type of the enclosing class or an immediate parent thereof, which would bypass any overrides by classes derived from it, but... | |
| May 26, 2015 at 17:56 | comment | added | cHao | There's no inherent requirement in MI that classes not call base methods, and no particular reason one would be needed. It seems a bit odd to blame MI, considering that problem also affects SI. | |
| May 26, 2015 at 15:52 | comment | added | supercat | ...(eschewing the syntax base.VirtualMethod) but I don't know of any language support to particularly facilitate such an approach. I wish there were a clean way to attach one block of code to both a non-virtual protected method and a virtual method with the same signature without requiring a "one-liner" virtual method (which ends up taking a lot more than one line in source code). | |
| May 26, 2015 at 15:47 | comment | added | supercat | @cHao: If one requires that derived classes must override parent methods and not chain to them (same rule as interfaces) one can avoid the problems, but that's a pretty severe limitation. If one uses a pattern where FirstDerivedFoo's override of Bar does nothing but chain to a protected non-virtual FirstDerivedFoo_Bar, and SecondDerivedFoo's override chains to protected non-virtual SecondDerivedBar, and if code that wants to access base method uses those protected non-virtual methods, that might be a workable approach... | |
| May 26, 2015 at 15:07 | comment | added | cHao | The problems with MI are easily solved or avoided altogether using the same techniques you'd use with single inheritance. None of the abilities/axioms you've mentioned is inherently hampered by MI except for the second one...and if you're inheriting from two classes that provide different behaviors for the same method, it's on you to resolve that ambiguity anyway. But if you find yourself having to do that, you're probably already misusing inheritance. | |
| Aug 3, 2014 at 18:54 | comment | added | supercat | Would down-voters claim to comment? I believe that my answer provides information not present in other languages, with regard to semantic advantages that can be received by disallowing multiple inheritance. The fact that allowing multiple inheritance would require giving up other useful things would be a good reason for anyone who values those other things more than multiple inheritance to oppose MI. | |
| Nov 14, 2013 at 22:14 | history | answered | supercat | CC BY-SA 3.0 |