This post is not a general introduction to type classes in Scala. There are quite a few good posts already on the subject (here, here and here for example), but it is about type classes and the somewhat-cryptic title require a brief explanation. In Scala with Cats, the authors describe a type class as a programming pattern that “allow us to extend existing libraries with new functionality, without using traditional inheritance, and without altering the original library source code.” Although that is not the only possible definition, it’s a perfect starting point for what I would like to cover. Can type classes help us at “removing” old functionalities in the same way? And how and why we might end up in such a situation? Let’s try to model a simple type for a bird to see how the issue could arise:
sealed trait Bird {
def fly: Unit
}
In a OOP approach we could proceed adding a few implementations, a parrot for example:
sealed trait Bird {
def fly: Unit
}
class Parrot(name: String) extends Bird {
override def fly: Unit = println(s"I'm a parrot and I can fly. My name is $name")
}
And perhaps a few other birds until we get to penguins. Penguins are birds, but there is a problem: penguins don’t fly.
sealed trait Bird {
def fly: Unit
}
class Penguin(name: String) extends Bird {
override def fly: Unit = ??? // throw new UnsupportedOperationException("Sorry, can't fly")
}
A solution might be to throw an UnsupportedOperationException but not an optimal one you might argue: catching those problems at compile time would be better. We probably were a bit rushed to add a fly method as part of the Bird trait. Not every birds flies and penguins are not the only exception. But was it just an oversight or there is more?
Ludwig Wittgenstein introduced in his Philosophical Investigations the the idea of family resemblance to describe certain concepts in our language for which we don’t have a clear set of traits shared across all members but more a general overlapping mesh of these features like in a large family picture where we can recognize each single member as part of the family and the common traits (hair color, shape of the nose, etc.) spread across them but where no definite set of those traits is shared by every single member.
Back to our problem, “flying” is such a common characteristic of birds that is almost understandable why that def fly slipped within the Bird trait.1
But perhaps there is something that a type class approach could do to mitigate those issues (all code available here2). Assume we have the same birds as above:
sealed trait Bird // no fly method now class Parrot(val name: String) extends Bird class Penguin(val name: String) extends Bird
And proceed defining the various components of our type classes. First the traits/behavior (note that there is no mention of Bird in them)
trait Fly[A] {
def fly(a: A): Unit
}
and
// for penguins
trait Swim[A] {
def swim(a: A): Unit
}
// for parrots
trait Talk[A] {
def talk(a: A): Unit
}
and then two instances implementing the above traits (one for a penguin and the other for a parrot):
implicit val parrotFly: Fly[Parrot] = new Fly[Parrot] {
def fly(parrot: Parrot): Unit = {
println(s"I'm a parrot and I can fly. My name is ${parrot.name}")
}
}
implicit val parrotTalk: Talk[Parrot] = new Talk[Parrot] {
def talk(parrot: Parrot): Unit = {
println(s"I'm a parrot and I can talk. My name is ${parrot.name}")
}
}
implicit val penguinSwim: Swim[Penguin] = new Swim[Penguin] {
def swim(penguin: Penguin): Unit = {
println(s"I'm a penguin and I can swim. My name is ${penguin.name}")
}
}
And finally the api, the last bit that acts like glue and, relying on implicits, puts everything together.
implicit class FlyOps[A](val value: A) extends AnyVal {
def fly(implicit flyInstance: Fly[A]): Unit = flyInstance.fly(value)
}
implicit class TalkOps[A](val value: A) extends AnyVal {
def talk(implicit talkInstance: Talk[A]): Unit = talkInstance.talk(value)
}
implicit class SwimOps[A](val value: A) extends AnyVal {
def swim(implicit swimInstance: Swim[A]): Unit = swimInstance.swim(value)
}
Now that we have all the pieces in place, we can see if we achieved something good out of it. We need two birds first:
val parrot = new Parrot("George")
val penguin = new Penguin("Pingu")
The api and instances defined above need to be imported for the implicits to do their magic:
// here is where I defined the api in the sample code import com.lansalo.family.resemblance.fp.api.ImplicitBehavioursApi._ // here the instances implementing the traits import com.lansalo.family.resemblance.fp.Instances._ parrot.fly // As expected, parrots can fly and this will output: // "I'm a parrot and I can fly. My name is George" parrot.talk // Will print: "I'm a parrot and I can talk. My name is George" parrot.swim // compilation error because parrots can't swim penguin.swim // will output: "I'm a penguin and I can swim. My name is Pingu" penguin.fly // compilation error, because penguin don't fly and more practically, // because we didn't define an instance for Fly[Penguin] // and the api will complain that one can't be found
So, both parrots and penguins are Birds but parrots can fly (but not swim) whereas penguins can swim (but not fly, or talk for that matter) and errors are picked up at compile time. All good then! Or not? Well… it turns out there is a friendly parrot in New Zealand that can’t fly: the kakapo (and apparently is the only one). Once again we found ourselves victims of the same mistake, to reiterate how easy it is to generalize and ignore edge cases. But perhaps this time we are in a better position to face the issue without the need to throw runtime errors (ie. UnsupportedOperationException) or to modify the data defined so far (which could be out of our control). Clearly a new member has to be added to the Bird family and even if it doesn’t fly, it still has to be a parrot:
sealed trait Bird class Parrot(val name: String) extends Bird class Penguin(val name: String) extends Bird class Kakapo(override val name: String) extends Parrot(name)
the Kakapo is still a parrot:
kakapo.isInstanceOf[Parrot] // returns true
But it can’t fly (kakapo.fly will not compile) although the reason might not be immediately clear. It’s true that we have an instance of Fly[Parrot] in scope and equally, a Kakapo is a parrot (as shown above) but their parent/child relationship doesn’t get propagated to the higher-kinded type Fly[A] as this is invariant in its type A.
For the same reason, the kakapo can’t talk like other parrots. I must admit that my knowledge on the whole kakapo subject is quite limited but from the information I gather, that seems to be the case. On the other hand, the ability to speak is widespread across the parrot family. It might well be that with a bit of patient training someone could teach few words to a kakapo. In that case, we can still adapt to this newly discovered behavior (still without modify our models) by adding an instance for it:
implicit val kakapoTalk: Talk[Kakapo] = new Talk[Kakapo] {
def talk(kakapo: Kakapo): Unit = {
println(s"I'm a kakapo and I can talk. My name is ${kakapo.name}")
}
}
Even if there is no perfect solution in those cases, a type class approach seems to provide a better way to deal with those scenarios where the we are trying to model concepts that relate to the family resemblance paradigm.
———————————
1. [All that remind me of my first experience as a developer, working for a big Italian utility company. It was long time ago and we were trying (among other things) to model a “meter reader” attached to user accounts. We were struggling with old legacy data and when we thought we capture the essence of a meter reader (and its types and hierarchy) it was just a matter of time and a new account pop up with a generally old type of reader, breaking our assumptions. It was then a matter to find someone with the know out in a position to throw some light on the weird new type. Usually someone close to retirement. ]↩
2. [The examples will rely on implicits, although, strictly speaking, type classes can be implemented without using them. In the code there are also few example of the more verbose version which does not use implicits]↩
Scala Notes 