Here is an UML diagram of "
IFloorWaxMixin". This is what re-motion mixins finds in the mixin configuration:
[ The sample is introduced in FIXME. ]
re-motion mixins derives a sub-class from the target class at run-time. That sub-class sports the members of the target class and all mixins that it uses. The sub-class implements the interfaces of all mixins. The member variable
_mixin is a collection of all used mixins. (Since we have only one mixin class in the samples, it is consequently referenced by
_mixin.) The mechanism discussed here is the same for "target class uses
mixin class" and "mixin class extends target class":
Under the hood, the new sub-class (actually named like
DessertTopping_Mixed_FIXME) implements the mixin classes' members by delegating the actual work to the corresponding mixins in
SealFloor(), for example, is implemented like this:
As you can see, this simple case essentially works like the one discussed in the video Mixins for Java: mixing is constructed with composition and delegation. [ http://www.berniecode.com/writing/java-mixins/ ]
If a method in the mixin class overrides a target method, re-motion mixins simply generates an extra declaration/delegation. For example, the method
TasteGood () in
DessertTopping does not need any mention in the derived (mixed) class. It is simple inherited from
TasteGood () were overridden by the
FloorWaxMixin, the extra delegation would be generated into the derived class, just like any other method from the mixin class:
What if a target method overrides a mixin method?
As the wiki page re-motion mixins basics -- overriding target methods#target overrides mixin? explains, "target method overrides mixin method" requires that the mixin class is derived from the generic
Mixin<TThis> type. The next wiki page FIXME will explain why this is so and how overriding mixin methods works.