Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Meh, that's just the standard composition vs inheritance dichotomy. In reality, those two concepts are orthogonal, and you can use one, the other, and both, as suitable to the situation.

Using multiple inheritance to implement certain common functionality, using mixin classes, is possible in Python; it's another powerful tool in the arsenal, but doesn't mean that you have to use it.

Inheritance works best to denote "is-a" relationships, i.e. for defining subtypes, especially when using type annotations and checks. Sometimes - albeit very rarely - you need a class that belongs to two separate type hierarchies; multiple inheritance comes very handy in those cases.



One case where I (ab)used this in R was to add an abstract class called Timed that measured the time the inner function took.

I guess I'd probably use a decorator in Python but this was R and I was on an S4 buzz back then so I took the approach above.


I don't think he is unaware of any of that. His point was that multiple inheritance involves enough fiddly surprising behaviour that it's best avoided - you are better off manually delegating to distinct member variables, then it is clear what is happening even if it is a bit more tedious.

(Btw that's the only way to implement inheritance in Rust, even single inheritance.)


> multiple inheritance involves enough fiddly surprising behaviour

In which way? MRO is very well defined.

> manually delegating to distinct member variables

Again, this is composition, which has nothing to do with inheritance. If you need to define a subtype, inheritance is most straightforward.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: