Skip to content

Instantly share code, notes, and snippets.

@nrinaudo
Created August 13, 2020 19:58
Show Gist options
  • Save nrinaudo/53459a49cd2131700a15a642f11526df to your computer and use it in GitHub Desktop.
Save nrinaudo/53459a49cd2131700a15a642f11526df to your computer and use it in GitHub Desktop.
Intro to a hypothetical talk on inheritance that I'll never have the courage to actually give

Hello, my name is Nicolas Rinaudo and I’m here today because I’d like to talk to you about one of the core features of our favourite language, one that we, as OOP programmers, should be intimately familiar with: inheritance.

Yes, I’m aware that there’s a fringe of the community that refuses to use inheritance on philosophical grounds, and I respect that. I just think it’s a bit of a shame because honestly, I couldn’t work without algebraic data types, and, well, Scala does them with inheritance. Or without type classes, for that matter - anybody that knows me knows I love my type classes - and they’re also done with inheritance in Haskell. I mean in Scala. Well, in both, really.

Don’t believe me? Here’s what the Haskell documentation has to say on the subject (https://www.haskell.org/tutorial/classes.html):

We say that Eq is a superclass of Ord (conversely, Ord is a subclass of Eq), and any type which is an instance of Ord must also be an instance of Eq.

And yes, I know. I’ve been told before that superclass and subclass are just accidental name collisions, because Haskell people tend to not be careful with their vocabulary. The subtyping relationship is not, in fact, inheritance. The fact that subclasses inherit code from their ancestors is not what most people mean with inheritance.

But what do we mean, then, when we say inheritance? Well, I propose we find out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment