

Mixins Considered Harmful - mace
http://www.artima.com/weblogs/viewpost.jsp?thread=246341

======
A1kmm
Haskell 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
Yes, 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.

