Stackable Traits Pattern in Scala (opens in new tab)

Trait in scala represents interface (your type understands some message) or "is a" relation (your type is more specific specialization of type). In your example it is not the case (Tywin is Jamie's father, which should be solved by composition). I do not think that Tywin, Jamie etc. is separate type. In my opinion, those are instances of some type. It is not good practise to call super implementation of method either. You are mixing inheritance and overriding, which in more complex programs always cause trouble (you may break inherited method by changing super implementation). You should solve this by composition (Jamie should not inherit Tywin addToDebt but should depend on Tywin for paying his depts).

I understand what you wanted to show but your example is really confusing and definitely is not correct.

I didn't intend to screw up the actual point, maybe I did but I think the actual point was still understandable, isn't it? If not please let me know the actual point where the article lost it in your case.

No, it wasn't impossible to follow, but the extra layer of indirection made me jump back to the top a few times to make sure I had everything straight.

    //Legacy
    abstract class Lannister

    //Father
    trait Tywin extends Lannister

could have just been:

    abstract class Family

    trait Father extends Family

Otherwise, I appreciate the article - it was informative.

Will try to improve in my next post :)

Maybe to make it more interesting, it turned out to complex as you are saying. But idea was not to use A, B, C etc. Will try to come up with something different next time.

It means there's a diversity of Scala styles; one person's Scala won't necessarily look like someone else's. More concretely it causes a lot of problems for type inference (particularly when ADTs in Scala are modeled as traits with implementing classes, so e.g. the type of Some(x) ends up as Some rather than Option). Other ML family languages that don't have traditional OO inheritance generally have perfect type inference (at least in the absence of higher kinds) via Hindley-Milner.

Not really, at all. Order the traits differently and you can get different behavior. Inherit one subtrait vs another and you can get different behavior. You can reason about all of this, but I'm not that smart, so I prefer composition.

Composition locks away the behavior you want so that you know exactly what you're getting.