Kotlin lets us define custom behaviour for operators (e.g.
*). We can add mathematical or logical semantics for how operators behave with various types.
We can either implement these behaviours in a class as a member function (handy for classes that we own), or externally, as an extension function (for types outside of our control).
First, let’s see what overloading is.
What is overloading?
Overloading functions is a practice which allow us to provide multiple functions with the same name (in the same scope), but with different signatures. This is desirable when the behaviour is the same or similar but the implementation has to be different for different types.
Consider the following class, which has a single function that’s used to sum two
Int values together:
We can add a second function with the same name, in the same scope (in this class), but only if we change the parameters to alter the signature:
Now we can say that we’ve overloaded the “sum” function; whenever we call
sum the function that it calls will depend on the types of the parameters we pass.
What is operator overloading in Kotlin?
Operator overloading is similar. Operators like minus, plus or equals have been defined to work with a subset of predefined types.
Let’s consider the
minus function which works with some types, like
minus(a: Int, b: Int)
a - b
b are of type
We learned at the start that we can overload operators by including them inside classes as member functions or outside classes as extension functions.
minus operator has multiple overloads defined as member functions in the
Let’s add another for a type that we define.
Overloading an operator for a new type
We have a data class that represents a tub (box?) of ice cream. It has one value, which is the number of scoops remaining in the tub (usually a low number for me):
minus(a: IceCreamTub, b: Int)
We saw the overloading example with member functions above for
Int, let’s demonstrate the same but using an extension function:
This will allow us to do something like this:
Could we do the opposite?
It doesn’t compile because there’s no function
minus defined on
Int that has
IceCreamTub as a parameter.
Let’s add it with an extension function (we can’t add a member function to the
Int class directly):
Oh. I actually don’t know what the return type should be for this function. It’s nonsense!
When should we (not) overload operators?
Problems, and critics, to the use of operator overloading arise because it allows programmers to give operators completely free functionality, without an imposition of coherency that permits to consistently satisfy user/reader expectations
from C++ Programming/Operators/Operator Overloading. No “imposition of coherency” mean that the writer is unrestricted to do what they like.
Did it make sense for us to overload the minus operator for
IceCream ? The two units aren’t even comparable to each other so maybe it didn’t make sense in the first place.
A regular function with a nicer name would serve us better.
We should be careful about overloading operators with types that might cause bewilderment (like with the
IceCreamTub combination) or worse, misunderstanding.
Useful instances of overloading
If you’ve used the Kotlin for even a few weeks, you’ll likely have come across instances of operator overloading already.
Collection type overloads the
plus operator. It lets us add elements from an
Iterable<T> to a
plus operator is further overloaded to support appending single elements:
And it even works with collections of different types — in this case, the type of
mix will be
The invoke() operator
invoke() operator allows instances of your classes to be called as functions.
Let’s create a class whose sole responsibility is taking a scoop of ice cream from the ice cream tub, then return the scoop and the tub (with the updated contents).
How would we use this?
ScoopAction is only designed to do one thing — it’s a little clunky to have to call a function on a class that solely represents an action.
Instead, we could overload the
The only differences are the addition of the
operator keyword and usage of
invoke as the function name.
We can further overload the same operator with more parameters:
Parentheses are translated to calls to
invoke with appropriate arguments.
Have I been using the invoke() operator already?
The most common place we encounter the
invoke() operator is with lambdas!
Lambdas are compiled to instances of the Function interfaces which all overload the
This lets us do the following:
So… should I use this in my project?
We looked at what operator overloading is and how to do it in Kotlin. We see that the operators serve as a shorthand for function calls, and consequently anything written with an operator can be written explicitly with the corresponding function.
1 + 2 instead of
1.plus(2) because it’s short, commonly understood and therefore easier to read, so we should apply the same logic when we’re deciding whether to overload operators with our own types:
- is it clear what the behaviour should be?
- would it be used often enough in your project to warrant the shorthand?
invoke() operator is a little different. It still provides you with a shorthand, but has no inherent behaviour/meaning of its own — it lends your classes the property of being actionable. If your class:
- represents a single action
- is named for a specific action
then go for it!
It doesn’t require any extra lines of code, it supports and highlights the responsibility of a single action for your class and it reduces verbosity at the call site.
As always, questions and comments welcome either here or on Twitter!