What Extension Functions Are Not
External implementations of interfaces, multi-methods, and what you can do instead
— — — — — — — — — — — — — — —
THE CURRENT VERSION OF THIS ARTICLE IS PUBLISHED HERE.
— — — — — — — — — — — — — — —
Tags: #FUNDAMENTAL CONCEPT
This article is part of the Kotlin Primer, an opinionated guide to the Kotlin language, which is indented to help facilitate Kotlin adoption inside Java-centric organizations. It was originally written as an organizational learning resource for Etnetera a.s. and I would like to express my sincere gratitude for their support.
It is recommended to read the Introduction before moving on. Check out the Table of Contents for all articles.
We’ve spent the previous few articles talking about what extension functions are, but it’s also important to understand what they are not. So let’s take a look at a couple of things that cannot be achieved using extension functions.
Implementing Interfaces Outside of a Class Definition
When discussing the motivation for extension functions, we mentioned the problem of not being able to have a DatabaseTable implement a Renderable interface when defining the renderTo function outside the class. Extension functions do not and cannot solve this problem.
Being able to have classes implement interfaces without changing their definition is something not usually supported in the C family of languages, with the exception of Swift and Scala. The technical term for the thing that would allow us to do this is a type class.
There was a long discussion about if and how to add similar capability to Kotlin, with the result being a shift towards extension functions with multiple receivers. This has now been implemented as context receivers, and I’ll talk about those in a different article.
However, you’re not without options:
You can use delegates
You can implement the interface contract using extension functions and pass an anonymous object “delegating” to those extension functions
Methods Belonging To Multiple Classes
At first glance, it might seem that you can, in fact, use extension functions to create a method belonging to more than once class.
In a way, the method above “belongs” to 2 classes at once, in the sense that there are two this values available and the method can only be called when both an A and B instance is in scope. However, there are two crucial differences:
- method receivers are dynamically dispatched, while extension function receivers are statically dispatched. In other words, the implementation to call is chosen by the runtime type of the receiver in the case of methods, but by the compile-time type of the receiver in the case of extension functions
- methods can use protected and private methods of the class it is defined on. Extensions can’t, because that would break encapsulation
The solution to the first problem is called multiple dispatch, and it is supported by some languages. Methods that take advantage of multiple dispatch are called “multi-methods”. Equivalent behavior can be emulated in Java/Kotlin, although it is a little unwieldy.
The second issue is usually not solvable even in languages which support multiple dispatch — in those languages, multi-methods are considered “outside” of all the classes. Indeed, languages with multiple dispatch often have no concept of encapsulation in the first place. For those interested, one of the few exceptions to this rule is Cecil.
Go back to Qualified This, jump to the Table of Contents, or continue to Extension Function Applications: Nullable & Generic Receivers.
