Covariant Nothing Object
In the previous part, we discussed the
invariance modifiers and their practical use cases.
Consider that you need to define a linked list data structure, which is a type of collection constructed by two types:
- node, which represents a linked list with at least one element and includes a reference to the first element (head) and a reference to the rest of the elements (tail).
- empty, which represents an empty linked list.
In Kotlin, we would represent such a data structure with a sealed class.
There is one problem though: for every linked list, we need a new object to represent the empty list. Every time we use
Empty(), we create a new instance. We would prefer to have only one instance that would serve wherever we need to represent an empty linked list. For that, we use object declaration in Kotlin, but object declarations cannot have type parameters.
There is a solution to this problem. We can make the
LinkedList type parameter covariant (by adding the
out modifier’). This is perfectly fine for a type that is only returned, i.e., for all type parameters in immutable classes. Then, we should make our
Empty object extend
Nothing type is a subtype of all types; so, if the
LinkedList type parameter is covariant, then
LinkedList<Nothing> is a subtype of all linked lists.
This pattern is used in many places, even in the Kotlin Standard Library. As you already know,
List is covariant because it is read-only. When you create a list using
emptyList, they both return the same object,
EmptyList, which implements
EmptyList is a subtype of all lists.
emptyList functions from Kotlin stdlib is actually the same object.
This pattern occurs in many places; for instance, when we define generic messages and some of them don't need to include any parameters, we should make them objects.
Even though this pattern repeats in Kotlin projects, I couldn't find a name that would describe it. I decided to name it the "Covariant Nothing Object". This is not a precise name; a precise description would be "pattern in which the object declaration implements a generic class or interface with the Nothing type argument used in the covariant type argument position". Nevertheless, the name needs to be short, and "Covariant Nothing Object" is clear and catchy.
Another example of a Covariant Nothing Object comes from a library my team co-created. It was used to schedule tasks in a microservice environment. For simplicity, you could assume that each task can be modeled as follows:
We needed to implement a mechanism to change scheduled tasks. We also needed to represent change within a configuration in order to define updates and pass them around conveniently. The old-school approach is to make a
TaskUpdate class which uses
null as a marker which indicates that a specific property should not change.
This approach is very limiting. Since the
null value is interpreted as "do not change this property", there is no way to express that you want to set a particular value to
null. Instead, we used a Covariant Nothing Object in our project to represent a property change. Each property might be either kept unchanged or changed to a new value. We can represent these two options with a sealed hierarchy, and thanks to generic types we might expect specific types of values.
This way, we achieved a type-safe and expressive way of representing task changes. What is more, when we use the Covariant Nothing Object pattern, we can easily express other kinds of changes as well. For instance, if our library supports default values or allows a previous value to be restored, we could add new objects to represent these property changes.
There are also cases where we want a class to implement a class or interface which uses the
Nothing type argument as a covariant type parameter. This is a pattern I call the Covariant Nothing Class. For example, consider the
Either class, which can be either
Right and must have two type parameters that specify what data types it expects on the
Left and on the
Right. However, both
Right should each have only one type parameter to specify what type they expect. To make this work, we need to fill the missing type argument with
With such definitions, we can create
Right without specifying type arguments.
Right can be up-casted to
Right with supertypes of the types of values they hold.
They can also be used wherever a result with the appropriate
Right type is expected.
This, in simplification, is how
Either is implemented in the Arrow library.
This ends the second part of this series. In the next part, we will discuss the limitations of variance modifiers.