Extension Functions: Syntax and Behavior

Extension functions & properties, what they are under the hood, and the consequences for encapsulation, visibility modifiers, the way they are dispatched, and more

— — — — — — — — — — — — — — —

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.

Types of Extensions

There are actually two types of extensions in Kotlin — extension functions and extension properties.

As seen in the previous article, extension functions are defined in the same way as regular functions, with the receiver prepended to the function name:

They are most often defined as top-level functions which can be imported in the same way as regular functions are, e.g. import a.b.c.repeatTwice for the example above. You can also define extension functions inside classes, which we will discuss more in a future article.

Things are very similar with extension properties:

In both cases, there are limitations to the way extension can be defined and used, but before we get to them, we’ll talk about what extensions actually are under the hood — this will lead to a very clear understanding of what the limitations are and why that is the case.

Under the Hood

Extension functions are actually nothing more than regular functions with a “hidden” first argument representing the receiver.

That’s it, really.

In fact, if you actually tried to define both of the above functions with the same name, you would get an error similar to Platform declaration clash: The declarations have the same JVM signature.

Consequences

It is really important to fully understand what we just said: extensions are just regular functions + syntactic sugar which hides a parameter and exposes it through this. Extensions don't modify classes and are in no way part of the class. Anything you can write with an extension, you can also write using a regular function which accepts the receiver as an explicit parameter:

Both do the same thing. No magic involved.

Let us explicitly list some consequences of the above:

• Extensions cannot access private and protected members of the classes they extend

Not having this limitation would cause a lot of problems because it would break encapsulation, but it also makes complete sense since extensions are nothing more than regular functions.

• Extension functions can have visibility modifiers, but they work in the same way as with top-level functions

• Extension properties can only be synthetic

Since extensions cannot actually modify classes, there is no way they could add a backing field to it. Another way to put it is that extensions are only functions, and functions can’t have backing fields associated with them.

• Extensions are dispatched statically

This makes perfect sense when seeing extensions for what they really are — regular functions with the receiver as the first argument. We are not overriding the function, but overloading it.

Go back to Extension Functions: Motivation, jump to the Table of Contents, or continue to Functions with Receiver.