3 ms·

There are two things I have always wondered: 1) if there are people who come back to using inheritance AFTER doing programming with typed systems that support

There are two things I have always wondered: 1) if there are people who come back to using inheritance AFTER doing programming with typed systems that support typeclasses (like Haskell). If so, would you able to articulate why you think inheritance is still a superior pattern? 2) if there were any use cases that could be solved using inheritance that could not be solved more elegantly without it?

nerdponx 9y ago
What are typeclasses if not inheritance? As someone without a formal CS background, a type with multiple typeclasses sure looks to me like a class inheriting from multiple interfaces.
- naasking 9y ago
  > What are typeclasses if not inheritance? Overloading not inheritance. It is closer to the notion of interfaces in traditional OO languages, but it's a mistake to confuse interface implementation as inheritance. This is a common problem with traditional OO languages: they conflate inheritance with subtyping, ie. "Y inherits the behaviour of X" is not always the same as "Y can be used anywhere an X can be used" (subtyping). C++ has "private inheritance" to separate these notions now, but it's a kludge from this initial design mistake. So type classes use subtyping, but not inheritance. Interface implementation is also closer to subtyping than inheritance.
- elnygren 9y ago
  OOP classes (well, their instances) combine data and functionality into a single "thing" (well, object). Inheritance is nasty because you are not just composing structures of data or interfaces of functionality but both at the same time. When you separate data from functionality into separate "things", composing things out of them becomes nicer. I'm not a Haskell programmer, but AFAIK type classes contain functionality, NOT data (state). Example of what I'm talking about: Clojure's Protocols.
marcosdumay 9y ago
> if there were any use cases that could be solved using inheritance that could not be solved more elegantly without it? There are behavior mixins, that you can look at Django views as an example. There are interface implementations when you want to have a few almost complete standard ones. Both are cumbersome to implement on Haskell. If you make sure to not use any widely used class, you can hack them out of some sets of hierarchical type classes with possible some overlapping. But leaving half-done stuff at your API to be filled by client code is never pretty there.

nerdponx 9y ago

What are typeclasses if not inheritance? As someone without a formal CS background, a type with multiple typeclasses sure looks to me like a class inheriting from multiple interfaces.

naasking 9y ago
> What are typeclasses if not inheritance? Overloading not inheritance. It is closer to the notion of interfaces in traditional OO languages, but it's a mistake to confuse interface implementation as inheritance. This is a common problem with traditional OO languages: they conflate inheritance with subtyping, ie. "Y inherits the behaviour of X" is not always the same as "Y can be used anywhere an X can be used" (subtyping). C++ has "private inheritance" to separate these notions now, but it's a kludge from this initial design mistake. So type classes use subtyping, but not inheritance. Interface implementation is also closer to subtyping than inheritance.
elnygren 9y ago
OOP classes (well, their instances) combine data and functionality into a single "thing" (well, object). Inheritance is nasty because you are not just composing structures of data or interfaces of functionality but both at the same time. When you separate data from functionality into separate "things", composing things out of them becomes nicer. I'm not a Haskell programmer, but AFAIK type classes contain functionality, NOT data (state). Example of what I'm talking about: Clojure's Protocols.

marcosdumay 9y ago

> if there were any use cases that could be solved using inheritance that could not be solved more elegantly without it? There are behavior mixins, that you can look at Django views as an example. There are interface implementations when you want to have a few almost complete standard ones. Both are cumbersome to implement on Haskell. If you make sure to not use any widely used class, you can hack them out of some sets of hierarchical type classes with possible some overlapping. But leaving half-done stuff at your API to be filled by client code is never pretty there.