Ahmed, Sorry about the delay replying. The first point can be decided in the derived class - the appropriate place to do so. Eiffel has solved this problem - before C++ even attempted it, you can simply rename one of the inherited A's, and it becomes obvious. Further, in a true message-based architecture, the question is redundant. All calls and data access are polymorphic, so D can simply define a method A to disambiguate - either by delegating to the original (in prototypical multiple inheritance) or explictly (otherwise). This gives true representation independence - you program to the interface of an object, not its implementation. Yes, it can be simulated by aggregation and interfaces, but that fails in the Comparable example I cited. In that example, defining one method in a class allows mixing in a lot of methods to provide a whole interface (<, <=, >=, >). This can save a lot of repetitive coding, fulfilling the basic principle of Don't Repeat Yourself (DRY). Self implements MI and has a radical inlining architecture. Often, a polymorphic message results in the actual code being inlined at the call site - with code injected to fall back to indirection when the type of the receiver is not amongst the most common cases. For many dispatches, this results in code that is nearly as optimal as hand-crafted C, and allows Self to adopt an approach where everything (including integers etc.) is an object in the real sense - the compiler (a JIT-based compiler) does all the work of making things efficient. It does very well - a fully dynamic compiler with execution times comparable to Java or C#, and frequently better. The lead developers of this were hired by Sun to work on the Java Hotspot compiler for this reason. I recommend looking at the Self documentation at least - looking at the class library there gives a good vision of how Multiple Inheritance is useful for solving real world problems, while avoiding the repetitive coding patterns that interfaces and aggregation based approximations lead to.