http://dpaste.dzfl.pl/c25655e2dfe9
The code above simplifies using interfaces as the programming object. It allows one to program the derived classes as if they were not part of an abstraction by mapping the abstracted virtual methods to concrete methods. e.g., class WindowsGui : iGui { WindowsButton _button; @property WindowsButton button(WindowsButton b) { return (_button = b); } mixin(Fixup!(WindowsGui, iButton, WindowsButton)); } instead of class WindowsGui : iGui { WindowsButton _button; @property iButton button(iButton b) { assert(cast(WindowsButton)b !is null, `Invalid object type dependency mismatch! Type: `~b.classinfo.name~` Type Expected: WindowsButton`); auto bb = cast(WindowsButton)b; // do work with bb. } } (note the check and the cast are required for all usages of iButton if one wants to treat it as a WindowsButton. By using the mix, no checks and no casts are required. Much cleaner looking and less verbose code results, which is the whole point.) One problem with the template is that b.classinfo.name returns the interface instead of the actual class. In the example on dpaste, b.classinfo.name returns iButton, the base interface of LinuxButton. I want to display the actual class name that causes the problem(LinuxButton trying to be used where a WindowsButton goes). Obviously the Fixup template is not robust nor optimized for all cases but should handle most.