Qualified This

An interesting problem that arises when extensions are introduced, and how to solve it using labels and qualified this

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

THE CURRENT VERSION OF THIS ARTICLE IS PUBLISHED HERE.

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

Tags: #KOTLIN FEATURE #EXERCISE

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.

With the introduction of extension functions and functions with receiver, we open the doors to an interesting situation. Take a look at the following:

The problem with the above is that, in A.printX, there are actually two candidate values for this — an A instance is in scope because printX is an extension function on A, and a B instance is in scope because A.printX is also a method (i.e. defined inside B). While the example may seem synthetic, it is not all that uncommon for this to happen.

A slightly different but equivalent situation can arise with function literals with receiver:

The issue here is almost identical — inside the runOnA block, we have two candidate values for this — the block is a function with receiver of type A, so an A instance is in scope inside the literal, but block is also defined as part of an extension function on B, which means that we have a B instance in scope as well.

Qualified this

This is identical to the situation encountered with inner classes, and the solution is also identical: if not qualified, a this expression refers to the innermost enclosing scope. If we want to refer to a different one, we need to qualify the this expression with a label by writing this@label.

Implicit labels are created for every class body and function statement (not literal) body. Here is an example describing all the possibilities:

This solves our problem when dealing with the receivers of statements (class and function definitions), but it still doesn’t help us with literals (anonymous functions & lambdas with or without receivers). However, as was mentioned in the chapter on inner classes, (explicit) labels can also be used to explicitly qualify expressions. You can use that to your advantage when dealing with conflicting receivers inside literals:

Exercises

It’s brain-fuck time! Spend some time thinking about what the abc function prints. Remember that -> is right associative, so the type bellow is the same as A.() -> (B.() -> (C.() -> Unit)).

Start reading: "The function 'abc', when invoked, returns a function with receiver A, which, when invoked, returns a function...". Contrast this with the number of invocations in main.

Think about what this function prints when run in its current form. Run the example — were you right?

Make changes so it evaluates to A B C:

Go back to Functions with Receiver, jump to the Table of Contents, or continue to What Extension Functions Are Not.