Composition versus Inheritance - Mixins.
Here is a Gist demonstrating the use of Mixins or Traits in Elm:
Often in OO programming we are told, “prefer composition over inheritance”. Large trees of classes with deep inheritance are successful ways of describing component based UI tool-kits, but rarely so successful in other domains.
Here is a set of game objects defined as an OO hierarchy (http://machinethink.net/blog/mixins-and-traits-in-swift-2.0/):
The issue in this example is that the Zap Monster and the Castle can both fire lasers guns, but no other objects in the game can. Once we have writen the laser gun code for a Zap Monster, how do we go about writing the same code for a Castle? We could copy-paste the code, which is almost always a bad idea. We could put the code on a base class further up the hierachy, on the GameObject class, but that means the code is available on other game objects that should not have it. A better way might be to put this code in a seperate class, ShootingHelper (or FireTrait in my Elm code), and to have an instance of that inside the Castle and Zap Monster classes to delegate to. This way of re-using code is called a mixin or trait.
It is the purpose of my Gist to show how this can be done in Elm. I only defined one trait in the Elm code, but you can see that is an extensible record, so traits can be combined.