Although our prototyping language does not offer multiple inheritance, assembling the various protocol layers through this code reuse mechanism is very appealing. The idea is to make each protocol class Object implement only protocol , 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.