Editing Multiple inheritance (section)

=== Mitigation ===

Languages have different ways of dealing with these problems of repeated inheritance.

* [[C Sharp (programming language)|C#]] (since C# 8.0) allows default interface method implementation, causing a class <code>A</code>, implementing interfaces <code>Ia</code> and <code>Ib</code> with similar methods having default implementations, to have two "inherited" methods with the same signature, causing the diamond problem. It is mitigated either by requiring <code>A</code> to implement the method itself, hence removing ambiguity, or forcing the caller to first cast the <code>A</code> object to the appropriate interface to use its default implementation of that method (e.g. <code>((Ia) aInstance).Method();</code>).
* [[C++]] by default follows each inheritance path separately, so a <code>D</code> object would actually contain two separate <code>A</code> objects, and uses of <code>A</code>'s members have to be properly qualified.  If the inheritance from <code>A</code> to <code>B</code> and the inheritance from <code>A</code> to <code>C</code> are both marked "<code>virtual</code>" (for example, "<code>class B : virtual public A</code>"), C++ takes special care to only create one <code>A</code> object, and uses of <code>A</code>'s members work correctly.  If [[virtual inheritance]] and nonvirtual inheritance are mixed, there is a single virtual <code>A</code>, and a nonvirtual <code>A</code> for each nonvirtual inheritance path to <code>A</code>. C++ requires stating explicitly which parent class the feature to be used is invoked from i.e. <code>Worker::Human.Age</code>. C++ does not support explicit repeated inheritance since there would be no way to qualify which superclass to use (i.e. having a class appear more than once in a single derivation list [class Dog : public Animal, Animal]). C++ also allows a single instance of the multiple class to be created via the virtual inheritance mechanism (i.e. <code>Worker::Human</code> and <code>Musician::Human</code> will reference the same object).
* [[Common Lisp]] [[Common Lisp Object System|CLOS]] attempts to provide both reasonable default behavior and the ability to override it. By default, to put it simply, the methods are sorted in <code>D,B,C,A</code>, when B is written before C in the class definition. The method with the most specific argument classes is chosen (D>(B,C)>A) ; then in the order in which parent classes are named in the subclass definition (B>C). However, the programmer can override this, by giving a specific method resolution order or stating a rule for combining methods. This is called method combination, which may be fully controlled. The MOP ([[metaobject]] protocol) also provides means to modify the inheritance, [[dynamic dispatch]], class instantiation, and other internal mechanisms without affecting the stability of the system.
* [[Curl (programming language)|Curl]] allows only classes that are explicitly marked as ''shared'' to be inherited repeatedly. Shared classes must define a ''secondary constructor'' for each regular [[constructor (computer science)|constructor]] in the class. The regular constructor is called the first time the state for the shared class is initialized through a subclass constructor, and the secondary constructor will be invoked for all other subclasses.
* In [[Eiffel (programming language)|Eiffel]], the ancestors' features are chosen explicitly with select and rename directives.  This allows the features of the base class to be shared between its descendants or to give each of them a separate copy of the base class. Eiffel allows explicit joining or separation of features inherited from ancestor classes. Eiffel will automatically join features together, if they have the same name and implementation. The class writer has the option to rename the inherited features to separate them. Multiple inheritance is a frequent occurrence in Eiffel development; most of the effective classes in the widely used EiffelBase library of data structures and algorithms, for example, have two or more parents.<ref>{{cite web|url=http://www.ecma-international.org/publications/standards/Ecma-367.htm|title=Standard ECMA-367|website=Ecma-international.org|access-date=2016-10-21}}</ref>
* [[Go (programming language)|Go]] prevents the diamond problem at compile time. If a structure <code>D</code> embeds two structures <code>B</code> and <code>C</code> which both have a method <code>F()</code>, thus satisfying an interface <code>A</code>, the compiler will complain about an "ambiguous selector" if <code>D.F()</code> is called, or if an instance of <code>D</code> is assigned to a variable of type <code>A</code>. <code>B</code> and <code>C</code>'s methods can be called explicitly with <code>D.B.F()</code> or <code>D.C.F()</code>.
* [[Java (programming language)|Java]] 8 introduces default methods on interfaces. If <code>A,B,C</code> are interfaces, <code>B,C</code> can each provide a different implementation to an [[abstract method]] of <code>A</code>, causing the diamond problem. Either class <code>D</code> must reimplement the method (the body of which can simply forward the call to one of the super implementations), or the ambiguity will be rejected as a compile error.<ref>{{cite web|url=http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-final.html|title=State of the Lambda|website=Cr.openjdk.java.net|access-date=2016-10-21}}</ref> Prior to Java 8, Java was not subject to the diamond problem risk, because it did not support multiple inheritance and interface default methods were not available.
* [[JavaFX Script]] in version 1.2 allows multiple inheritance through the use of [[mixin]]s. In case of conflict, the compiler prohibits the direct usage of the ambiguous variable or function. Each inherited member can still be accessed by casting the object to the mixin of interest, e.g. <code>(individual as Person).printInfo();</code>.
* [[Kotlin (programming language)|Kotlin]] allows multiple inheritance of Interfaces, however, in a Diamond problem scenario, the child class must override the method that causes the inheritance conflict and specify which parent class implementation should be used. eg <code> super<ChosenParentInterface>.someMethod()</code>
* [[Logtalk]] supports both interface and implementation multi-inheritance, allowing the declaration of method ''aliases'' that provide both renaming and access to methods that would be masked out by the default conflict resolution mechanism.
* In [[OCaml]], parent classes are specified individually in the body of the class definition.  Methods (and attributes) are inherited in the same order, with each newly inherited method overriding any existing methods. OCaml chooses the last matching definition of a class inheritance list to resolve which method implementation to use under ambiguities. To override the default behavior, one simply qualifies a method call with the desired class definition.
* [[Perl]] uses the list of classes to inherit from as an ordered list. The compiler uses the first method it finds by [[depth-first search]]ing of the superclass list or using the [[C3 linearization]] of the class hierarchy. Various extensions provide alternative class composition schemes. The order of inheritance affects the class semantics. In the above ambiguity, class <code>B</code> and its ancestors would be checked before class <code>C</code> and its ancestors, so the method in <code>A</code> would be inherited through <code>B</code>. This is shared with [[Io (programming language)|Io]] and [[Picolisp]]. In Perl, this behavior can be overridden using the <code>mro</code> or other modules to use [[C3 linearization]] or other algorithms.<ref>{{cite web|url=http://perldoc.perl.org/perlobj.html#Method-Resolution-Order |title=perlobj |website=perldoc.perl.org |access-date=2016-10-21}}</ref>
* [[Python (programming language)|Python]] has the same structure as Perl, but, unlike Perl, includes it in the syntax of the language. The order of inheritance affects the class semantics. Python had to deal with this upon the introduction of new-style classes, all of which have a common ancestor, <code>object</code>. Python creates a list of classes using the [[C3 linearization]] (or Method Resolution Order (MRO)) algorithm. That algorithm enforces two constraints: children precede their parents and if a class inherits from multiple classes, they are kept in the order specified in the tuple of base classes (however in this case, some classes high in the inheritance graph may precede classes lower in the graph<ref>{{cite web|author=Abstract |url=https://www.python.org/download/releases/2.3/mro/#examples |title=The Python 2.3 Method Resolution Order |website=Python.org |access-date=2016-10-21}}</ref>). Thus, the method resolution order is: <code>D</code>, <code>B</code>, <code>C</code>, <code>A</code>.<ref>{{cite web|url=https://www.python.org/download/releases/2.2.3/descrintro/#mro |title=Unifying types and classes in Python 2.2 |website=Python.org |access-date=2016-10-21}}</ref>
* [[Ruby (programming language)|Ruby]] classes have exactly one parent but may also inherit from multiple ''modules;'' ruby class definitions are executed, and the (re)definition of a method obscures any previously existing definition at the time of execution.  In the absence of runtime metaprogramming this has approximately the same semantics as rightmost depth first resolution.
* [[Scala (programming language)|Scala]] allows multiple instantiation of ''traits'', which allows for multiple inheritance by adding a distinction between the class hierarchy and the trait hierarchy. A class can only inherit from a single class, but can mix-in as many traits as desired. Scala resolves method names using a right-first depth-first search of extended 'traits', before eliminating all but the last occurrence of each module in the resulting list. So, the resolution order is: [<code>D</code>, <code>C</code>, <code>A</code>, <code>B</code>, <code>A</code>], which reduces down to [<code>D</code>, <code>C</code>, <code>B</code>, <code>A</code>].
* [[Tcl]] allows multiple parent classes; the order of specification in the class declaration affects the name resolution for members using the [[C3 linearization]] algorithm.<ref>{{cite web|url=http://www.tcl.tk/man/itcl3.1/class.n.html |title=Manpage of class |website=Tcl.tk |date=1999-11-16 |access-date=2016-10-21}}</ref>

Languages that allow only [[single inheritance]], where a class can only derive from one base class, do not have the diamond problem. The reason for this is that such languages have at most one implementation of any method at any level in the inheritance chain regardless of the repetition or placement of methods. Typically these languages allow classes to implement multiple [[protocol (object-oriented programming)|protocol]]s, called [[interface (Java)|interfaces]] in Java. These protocols define methods but do not provide concrete implementations. This strategy has been used by [[ActionScript]], [[C Sharp (programming language)|C#]], [[D (programming language)|D]], [[Java (programming language)|Java]], [[Nemerle]], [[Object Pascal]], [[Objective-C]], [[Smalltalk]], [[Swift (programming language)|Swift]] and [[PHP]].<ref>{{cite web|url=http://php.net/manual/en/language.oop5.interfaces.php |title=Object Interfaces - Manual |website=PHP.net |date=2007-07-04 |access-date=2016-10-21}}</ref> All these languages allow classes to implement multiple protocols.

Moreover, [[Ada (programming language)|Ada]], C#, Java, Object Pascal, Objective-C, Swift and PHP allow multiple-inheritance of interfaces (called protocols in Objective-C and Swift).  Interfaces are like abstract base classes that specify method signatures without implementing any behaviour.  ("Pure" interfaces such as the ones in Java up to version 7 do not permit any implementation or instance data in the interface.)  Nevertheless, even when several interfaces declare the same method signature, as soon as that method is implemented (defined) anywhere in the inheritance chain, it overrides any implementation of that method in the chain above it (in its superclasses).  Hence, at any given level in the inheritance chain, there can be at most one implementation of any method.  Thus, single-inheritance method implementation does not exhibit the diamond problem even with multiple-inheritance of interfaces. With the introduction of default implementation for interfaces in Java 8 and C# 8, it is still possible to generate a diamond problem, although this will only appear as a compile-time error.

{{see also|Comparison of C Sharp and Java#Explicit interface implementation}}