3 ms·

I think that it does not make sense that Jamie extends Tywin etc. This is not "is a" relation.

by oselhn 11y ago

jinst8gmi 11y ago
I think it's more that Joffrey etc. inherits certain traits from his parents rather that is his parents.
acjohnson55 11y ago
That's a good point. It's one of the things that confused me about trait stacking when I first started learning Scala. People often effectively use traits to implement composition, in the sense that the intention isn't that you would take advantage of Liskov substitution, but rather you intend to aggregate behavior from a number of sources. It's one of many ways in Scala where a single abstract construct could have several different semantics applied to it.
akavi 11y ago
Yeah, the author is being cute with the word "inheritance", which ends up obscuring the actual point.
- saheb37 11y ago
  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.
saheb37 11y ago
traits in Scala doesn't always have to be in a "is a" relationship. If it makes you understand then think of them as adding behavior/mixins. And about why the syntax confused you, the first "with" trait has to be extended, if it could replace extends with "with" in case of traits then maybe you would have liked it better.
- oselhn 11y ago
  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.
  - saheb37 11y ago
    I agree its not a real life example :) It was never meant to be. And definitely there is some better approach to implement the same hierarchy.

I think that it does not make sense that Jamie extends Tywin etc. This is not "is a" relation.

by oselhn 11y ago

I think that it does not make sense that Jamie extends Tywin etc. This is not "is a" relation.

jinst8gmi 11y ago

I think it's more that Joffrey etc. inherits certain traits from his parents rather that is his parents.

acjohnson55 11y ago

That's a good point. It's one of the things that confused me about trait stacking when I first started learning Scala. People often effectively use traits to implement composition, in the sense that the intention isn't that you would take advantage of Liskov substitution, but rather you intend to aggregate behavior from a number of sources. It's one of many ways in Scala where a single abstract construct could have several different semantics applied to it.

akavi 11y ago

Yeah, the author is being cute with the word "inheritance", which ends up obscuring the actual point.

saheb37 11y ago
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.

saheb37 11y ago

traits in Scala doesn't always have to be in a "is a" relationship. If it makes you understand then think of them as adding behavior/mixins. And about why the syntax confused you, the first "with" trait has to be extended, if it could replace extends with "with" in case of traits then maybe you would have liked it better.

oselhn 11y ago
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.
- saheb37 11y ago
  I agree its not a real life example :) It was never meant to be. And definitely there is some better approach to implement the same hierarchy.