Talk:Multiple inheritance

POV

Compare the most recent edit (10:09, 3 January 2007) to the one before it (13:34, 22 December 2006). I actually agree that Multiple Inheritance is very useful and its problems can be overcome, but this is pretty blatant POV. If there are no objections, I'll revert it tomorrow. 152.23.77.52 17:46, 17 January 2007 (UTC)

Instancing in .NET

Regarding the second paragraph, I believe the .NET languages (or at least C# and VB) have an Interface rule as well. MSDN has an article on it. I'm not confident enough in my knowledge of programming languages in general and Java in particular to say whether this is really the same thing as what's being discussed in paragraph two, but they look pretty similar to me. Jonathan Lurie of Builder.Com has an article on the subject in which he discusses the two to some extent.

MSDN article: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbls7/html/vblrfvbspec4_2_2.asp

Lurie's article: http://builder.com.com/5100-6373-5030734.html

Adding this information to the second paragraph. -- Pangloss

Multiple vs. Single Inheritance

Regarding the paragraph beginning "Multiple inheritance has been a touchy issue for many...": Aside from the problems introduced for the user of multiple inheritance, isn't there also implementation overhead that influences this decision? (Specifically, I think that a typical compiled multiple-inheritance implementation incurs a larger object reference size and additional run-time code for upcasting.) If this overhead actually deters language designers from including multiple inheritance in their language, then it should be mentioned here. I'm not sure enough to make the change myself.

I've had trouble finding any web pages that discuss the implementation of multiple inheritance. Some more external links here would be great. --barryd 05:05, 9 March 2006 (UTC)

I think the relative implementation costs depend mostly on the general design of language in question, rather than whether it follows multiple or single inheritence. In Python, for example, the difference almost comes down to just the MRO calculation algorithm, and the number of parents in each class's __base(s)__ attribute. (In either case, the overhead depends mostly on the size/depth of the inheritence hierarchy, if anything, rather than how it was calculated.)

I don't think there's anything inherently hard/slow to implement about multiple inheritence; rather, the problem is deciding which kind of multiple inheritence to implement in the first place. --Piet Delport 03:47, 10 March 2006 (UTC)

I suppose my focus was initially on compiled (perhaps better expressed as "VMT-based") OO languages. It's clear that implementation considerations differ greatly between compiled and interpreted OO languages (In a compiled VMT-based language, the MRO will be resolved in the generation of the VMT at compile time, and heirarchy size will have no run-time impact. With such low overheads, a small overhead due to inheritance style can be significant). That said, all the popular, well-known OO languages do seem to implement multiple inheritance in some form now, suggesting that the benefits are too great to ignore, or the costs insignificant.

When I initially read the article, I was hoping it would provide me with information to help answer the question "Why were VMT-based languages Java and C#/.NET designed to use interfaces instead of supporting multiple inheritance in similar fashion to C++?". I thought there must be some reason why an abstract class and multiple inheritance wasn't considered a more suitable way of doing interfaces. Perhaps I was jumping to conclusions to suggest the reason had to be somewhere under the hood. --barryd 05:33, 20 March 2006 (UTC)

"It's clear that implementation considerations differ greatly between compiled and interpreted OO languages."

Minor nitpick: i think you mean "static" and "dynamic", instead of "compiled" and "interpreted". :)

"Why were VMT-based languages Java and C#/.NET designed to use interfaces instead of supporting multiple inheritance in similar fashion to C++?"

Most languages that limit themselves to single inheritence probably do so because multiple inheritence is commonly percieved to be complicated and confusing; something which C++ itself is probably mostly responsible for. It's the most well-known and visible multiple-inheritence-supporting language out there, and yet its support for actually using multiple inheritence is so tragically limited that it becomes all but unusable for cooperative method implementations, mixins, and most other useful applications of multiple inheritence. If you haven't been exposed to other languages that do multiple inheritance "right", it's easy to think that these are problems with multiple inheritence, instead of with C++.

Anyway, for a great (and more complete) overview of the resolution order problem, and a solution, see A Monotonic Superclass Linearization for Dylan.

--Piet Delport 12:02, 27 March 2006 (UTC)

Of the languages that do multiple inheritance better than C++, are any of them static, compiled languages? Can anyone provide some language names? --barryd 22:57, 2 April 2006 (UTC)

At least Common Lisp/CLOS, Dylan, and Eiffel (which approaches the multiple inheritence problem somewhat differently, from what i hear). Python is moving in that direction (compiled, optional static typing) as well, with things like PyPy. --Piet Delport 03:13, 4 April 2006 (UTC)

I suggest to add the article a note about MI in Python, it can also be used to supply the article some real MI code.

Comments

I just wanted to note a Recent discussion in the Microsoft C@ language forum ...

http://msdn.microsoft.com/newsgroups/default.aspx?dg=microsoft.public.dotnet.languages.csharp&lang=en&cr=US

... that is relevant to an articulate and definitive definition of Multiple Inheritance.

See Thread : Strategic Functional Migration and Multiple Inheritance

Introduced in this discussion is the importance of separating the following issues relevant to Multiple Inheritance.

[1] Syntax [2] Composition [3] Under the cover (compiler implementation) issues

In dropping these issues (temporarily of course) we were able to focus the discussion of MI to its utility in the structural aggregation of the target functionality.

A key concept introduced in the discussion is Shawnk's (USA) term of 'functional normalization' to qualify Redek Cerny's comment regarding normalizing code functionality via Multiple Inheritance (MI).

Redek Cerny's (Australia) excellent comment on 'functional normalization' is a concise term to articulate the 'realized benefit' of MI relative to providing a structural aggregation mechanism while still retaining the functional normalization of the orignal code base.

Functional normalization may well be the core architectural impetus of Multiple Inheritance (MI).

It appears (jury still out) that C# and .NET do not support a functionally normalized code base BECAUSE there is no support for MI in any .NET language.

The importance of a functionally normalized code base to programming is equal to the importance of a normalized data base in data base systems.

I encourage all contributors to the WikiPedia definition of Multiple Inheritance to review Redek Cerny's contribution to the SFM (Strategic Functional Migration) discussion.

The term 'functional normalization' may be an important qualifier to better articulate the benefits and architectural impetus of Multiple Inheritance.

Shawnk

---

I suggest that the 'see Also' section should contain a link to the Interfaces WikiPedia page. A link to an 'Implementation Inheritance' page should also be made when that page is created.

Shawnk

There is two Common Lisp solution to diamond inheritance problem written here. Can we get rid one of them. — Preceding unsigned comment added by 95.10.101.218 (talk) 23:47, 26 August 2012 (UTC)

Multiple subtyping

The text suggests that the problems of multiple inheritance go away by using interfaces (see the last paragraph of the introduction). This is not true: most of the problems are related to multiple subtyping (having multiple paths through the type hierarchy to the same parent) and not multiple inheritance (getting the same code multiple times). I really think that there is a clarification needed. --Schoelle 18:47, 14 November 2007 (UTC)

Debate: Example

The example using Filter circuits and their components is quite poor - while a fair example, those not used to fundamental electronics will not be able to grasp the example. Much better to use something everyone understands, such as bikes and cars, the de facto standard example objects for OOP problems. dimo414 (talk) 06:29, 25 May 2008 (UTC)

Agreed, and done. Joe (talk) 14:40, 23 September 2008 (UTC)

Sorry, but the provided example seems a little unclear to me. I'm not sure if it was saying in multiple inheritance the streetMusician inherited from Human, Musician, and Worker, or if it inherited Musician, which inherited from Worker, which inherits human. As well, because Musician inherits from Worker and Human, is it even necessary for StreetMusician to inherit from these if it already inherits Musician? 184.33.23.14 (talk) 05:38, 7 October 2010 (UTC)

Origins

Maybe the article can indicate the earliest language to utilize this feature.72.84.141.136 (talk) 17:37, 23 March 2009 (UTC)

indeed, that'd be great! my bet is on lisp! 79.193.83.44 (talk) 22:21, 23 September 2009 (UTC)

Order of inheritance changes class semantics

Hi there, can we please have a minimal example of this behaviour, if possible in C++? This is the first time I hear this claim and I could not replicate it. Thank you. 118.7.198.171 (talk) 08:25, 14 June 2009 (UTC)

Copyvio problems

This page was flagged as a copyright problem at Wikipedia talk:India Education Program#Multiple inheritance and listed at Wikipedia:Copyright problems/2011 November 2. I've now reverted to the last pre IEP revision. Further

"The Overview section from "Multiple inheritance allows" to the end of the three line table is an almost word for word copy of section 1.11.6.1 from Object Oriented Modeling And Design By B.S.Ainapure ([1]). -84user (talk) 22:30, 3 November 2011 (UTC)"

this seems to be a pre IEP problem dating back to 2007 [2]. I've now replace that with an earlier version [3].--Salix (talk): 09:49, 8 November 2011 (UTC)

copied from User talk:Salix alba, move here to keep discussion in one place--Salix (talk): 18:12, 9 November 2011 (UTC)

Hi. I have not done any copyvio on my project page Multiple Inheritance. But I see you have reverted back all my changes. May I know why have you done that? Also the entire material as well as diagrams were made by me. There were some users who said that the definition seem to be possible copyvio. So I changed that. Other than that there was nothing that was copied. So I request you to please bring back my changes. RAJATPASARI (talk) 17:13, 9 November 2011 (UTC)

Other uses brought attention to the copyvio issue on Wikipedia talk:India Education Program#Multiple inheritance and indeed two different of copyvios were found, although it does seem that yours do not seem to be copyvios. There are problems with your edits though, the image is poor and blurry, it would be better done in SVG. Further its somewhat confusing as you are using the same arrow type for inheritance and labelling. I've got to rush now but I'll have a closer look to see what can be kept.--Salix (talk): 18:12, 9 November 2011 (UTC)

Python MRO: children don't always precede their parents

In section "Mitigation", item "Python", it is currently stated that "That algorithm [C3] enforces two constraints: children precede their parents". Unless I'm mistaken, this is not correct, see the second example here: http://www.python.org/download/releases/2.3/mro/#examples. Since I'm not an expert pythonist, I'd like someone more experienced than me to comment before editing this sentence. Manuel (mpg) (talk) 14:08, 21 September 2012 (UTC)

Hum, I now realise I didn't pay attention: "children always precede their parents" does not mean the same as "all parents always precede any grandparent". I remove the "dubious" template and added a sentence which hopefully helps make things clearer. Manuel (mpg) (talk) 19:31, 24 September 2012 (UTC)

Link to german site

Hi. In the Languages Section of this Article, when i click on "Deutsch" (German) it leads to the Diamond Problem (in german Wikipedia, this Problem has it's own Article). But there is an Article about Multiple Inheritance as well here: https://de.wikipedia.org/wiki/Mehrfachvererbung Could one of you please correct that? I tried to google how to do that, but couldnt find the answer. Thanks in Advance!

Java and Multiple Interfaces

I've create Java classes that worked fine with multiple interfaces in Java 5-7, and seen other code that does this. Clearly this was allowed before Java 8, unless I've slipped into a parallel time line. As the alternative seems ridiculous I must be a simple and absolute fact that Java allowed multiple interfaces (though not true multiple inheritance) before Java 8. --50.149.180.189 (talk) 16:30, 6 July 2014 (UTC)

Scala vs. Java

Is it consistent that Scala is marked as featuring MI while Java, whose object system it uses, after having upgraded to the most possible degree, is marked as not? Scala's traits are not classes but generalization of Java's interfaces (actually, typeclasses built on top of those, heh?). In Scala, a type has only one parent type and mixins are but types with traits. — Preceding unsigned comment added by 31.173.81.65 (talk) 01:11, 13 February 2016 (UTC)

Rust

Somebody who understands the Rust language should add a paragraph to the Mitigation section about how Rust avoids the Diamond problem. —MiguelMunoz (talk) 21:43, 27 November 2020 (UTC)

India Education Program course assignment

This article was the subject of an educational assignment at College Of Engineering Pune supported by Wikipedia Ambassadors through the India Education Program during the 2011 Q3 term. Further details are available on the course page.

The above message was substituted from {{IEP assignment}} by PrimeBOT (talk) on 19:58, 1 February 2023 (UTC)