Post from Kodumaro.
The other day, talking to some coworkers, I realised developers unacquainted to functional programming find hard to understand type covariance and contravariance abstractions.
So I thought about an analogy to make it easier.
Type contravariance
Let’s define two classes that represent something easy to get in mind: dogs. Shepherds are dogs, so (in Scala):
class Dog
class Shepherd extends Dog
We have a job for a dog trainer. Think about a Shepherd pack needing to be trained.
The job title is “Shepherd trainer”, but a dog trainer – someone who know how to train every kind of dog – is competent for the job:
class Trainer[-A]
val trainerJob: Trainer[Shepher] = new Trainer[Dog]
That’s okay! But a Shepherd trainer couldn’t take a general dog trainer job, ’cause he has no experience with training other kinds of dog.
This is contravariance:
// If:
implicitly[Shepherd <:< Dog]
// Then:
implicitly[Trainer[Dog] <:< Trainer[Shepherd]]
⦅<:<
means “is subclass of,” or: every Shepherd
is a Dog
too, so every Trainer[Dog]
is a Trainer[Shepherd]
too.⦆
In Scala we use -
to represent contravariance.
Type covariance
Now imagine that we need to hire a dog producer. We’re not interested in what kind of dog he’ll supply, any kind is great.
So a Shepherd producer could apply for the service, ’cause Shepherd dogs are so good as any other.
class Producer[+A]
val producerContract: Producer[Dog] = new Producer[Shepherd]
It’s called covariance:
// If
implicitly[Shepherd <:< Dog]
// Then
implicitly[Producer[Shepherd] <:< Producer[Dog]]
⦅Yet every Producer[Shepherd]
is a Producer[Dog]
too – he produces only dogs.⦆
In Scala we use +
to represent covariance.
Top comments (0)