Check out the new USENIX Web site. next up previous
Next: Toolbox Approach Up: Design Alternatives Previous: Design Alternatives

Multiple Inheritance and Mixins

Although our prototyping language does not offer multiple inheritance, assembling the various protocol layers through this code reuse mechanism is very appealinggif. The idea is to make each protocol class tex2html_wrap_inline777 Object implement only protocol tex2html_wrap_inline777, while accessing all required underlying protocols through unimplemented operations; each protocol class is then an abstract class and we usually say it is a mixin class or simply a mixin. Before being able to actually instantiate a protocol object, one first has to build a new class deriving from all the necessary mixins.

There are three major drawbacks with this approach. First, protocol classes are not more ready-to-use components: a fairly complex multiple subclassing phase is now required. As consequence, programmers have to deal with protocol relationships ``manually''. Second, protocol layers can only be assembled through subclassing, and it is thus difficult to compose protocol at runtime if not impossible: in several programming languages, e.g., C++, classes are only compile-time entities. Third, we still have to manage concurrent protocol executions within the same protocol object, while this problem is handled nicely as soon as algorithms are manipulated as objects.

Wed May 14 17:28:46 MET DST 1997