Covariant Nothing Object
This is a chapter from the book Advanced Kotlin. You can find it on LeanPub.
In the previous part, we already discussed variance modifiers
out
andin
, as well as their practical use cases.
Consider that you need to define a linked list data structure. It 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 the 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, so add the out
modifier, which is perfectly fine for the type that is only returned, so for all type parameters in immutable classes. Then we should make our Empty
object extend LinkedList<Nothing>
. The type Nothing
is the subtype of all the 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 Kotlin Standard Library. As you already know, List
is covariant because it is read-only. When you create a list using listOf
or emptyList
, they both return the same object, EmptyList
, which implements List<Nothing>
, so this way, EmptyList
is a subtype of all the lists.
listOf
or emptyList
functions from Kotlin stdlib is actually the same object.I could observe this pattern in many places, for instance when we define generic messages, and some of them do not need to include any parameters, we like to 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 "Covariant Nothing Object". It is not a precise name, as a precise description would be "pattern, where object declaration implements a generic class or interface with Nothing type argument used on covariant type argument position". Nevertheless, the name needs to be short, and "Covariant Nothing Object" is a clear and catchy name.
Another example of 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. What is more, we would like to represent change with a class, to create it and pass it around conveniently. The old-school approach is to make a class TaskUpdate
, which uses null
as a marker 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 Covariant Nothing Object to represent property change. Each property might be either kept unchanged or changed to a new value. We can represent those 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 to represent 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 allows restoring a previous value or supports default values, we could add new objects to represent those property changes.
Covariant Nothing Class
There are also cases where we want a class to implement a class or interface with the Nothing
type argument used for a covariant type parameter. This is a pattern I call Covariant Nothing Class. For example, consider the Either
class, which can be either Left
or Right
. The class Either
must have two type parameters to specify what data types it expects on Left
and what on Right
. However, Left
should have only one type parameter to specify what type it expects. The same with Right
. To make it work, we need to fill the missing type argument with Nothing
.
With such definitions, we can create Left
or Right
without specifying type arguments.
Both Left
and Right
can be up-casted to Left
and Right
with supertypes of the types of values they hold.
They can also be used wherever the result with appropriate Left
and Right
type is expected.
This, in simplification, is how Either
is implemented in the Arrow library.
That ends the second part of this series. In the next one, we will discuss variance modifier limitations.