3 ms·
Mixins Considered Harmful
- A1kmm 16y agoHaskell can solve the same problem that mixins solve, with typeclasses, much more elegantly. Because Haskell isn't object orientated, it is possible to simply not import functions which are not desired, rather than running into namespace pollution problems. For example, suppose that RoundThings have a diameter, and it MovedThings have an offset from the original position. class RoundThing a where diameter :: a -> Double radius :: a -> Double radius a = diameter a / 2 circumference :: a -> Double circumference a = 2 * pi * (radius a) class MovedThing a where offset :: a -> Double class MovedRoundThing a where rotationsMoved :: (MovedThing a, RoundThing a) => a -> Double rotationsMoved a = offset a / circumference a data MovedBall = MovedBall Double Double instance RoundThing MovedBall where diameter (MovedBall dia _) = dia instance MovedThing MovedBall where offset (MovedBall _ offs) = offs instance MovedRoundThing MovedBall main = do let myBall = MovedBall 10 20 print (rotationsMoved myBall) I don't have to worry about, say, rotationsMoved polluting my namespaces, because if I don't want to import it, I don't have to.
- stcredzero 16y agoYes, a design based on mixins is harmful, for the exact same reasons why designs based on multiple inheritance in C++ were often awkward. (Our industry does have a problem with ignoring its own history.) These mechanisms should be used sparingly to resolve conflicts and sticky design problems. They should not be used as a substitute for composition.