Designing: Multiple interfaces implementation on classes
-
I don't believe vtables and virtual functions are what make MI difficult, or at least it's only part of the reason. Rather it's the data, from my experience, that makes MI difficult. Consider two classes, B & C which both inherit from A. Now make class D which inherits both from B & C. Now without declaring A to be a virtual base class, then when B or C calls a method on A which A should it call it on? Or when casting an instance of D to A, what inheritance chain should be followed? Also, in my experience, MI has only a few applications and can be simulated, where needed, by aggregation and interfaces.
Rob Grainger wrote:
The vtable/indirection approach has drawbacks in pipelined architectures - every polymorphic message call results in jump, causing the pipeline to be refreshed at best, at worst resulting in cache misses
How is this different from message passing? Doesn't a jump to the requisite code occur eventually?
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von BraunAhmed, 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.