Talk:Multiple inheritance

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)[reply]

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)[reply]

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)[reply]

"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)[reply]

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)[reply]

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)[reply]

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