Extension properties in Kotlin - Deep Dive

Overview - Extension properties

What is it?

Extension properties in Kotlin let you add new properties to existing classes without changing their source code. They look like regular properties but are defined outside the class. This helps you add useful features to classes you don't own or can't modify. However, extension properties cannot store data; they only provide computed values.

Why it matters

Extension properties solve the problem of enhancing classes without inheritance or modifying original code. Without them, you would need to create wrapper classes or modify the original class, which is often impossible or cumbersome. This makes your code cleaner, more readable, and easier to maintain when working with third-party or built-in classes.

Where it fits

Before learning extension properties, you should understand basic Kotlin properties and functions. After mastering extension properties, you can explore extension functions, delegation, and advanced Kotlin features like inline classes and DSLs.

Mental Model

Core Idea

Extension properties let you add new, computed properties to existing classes externally, without changing their original code or storing new data.

Think of it like...

It's like adding a new label to a book's cover without opening or changing the book inside. The label shows extra information computed from the book's content but doesn't alter the book itself.

Class OriginalClass
┌─────────────────────┐
│ existing properties  │
│ existing functions   │
└─────────────────────┘
          ↑
          │
          │ Extension property adds:
          │
┌─────────────────────┐
│ val OriginalClass.newProperty: Type
│   get() = computedValue
└─────────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Kotlin properties

Concept: Learn what properties are in Kotlin and how they work with getters and setters.

In Kotlin, a property is like a variable attached to a class. It can have a backing field to store data, and custom getter and setter functions to control access. For example: class Person { var name: String = "" get() = field set(value) { field = value } } Here, 'name' stores data and can be read or changed.

Result

You understand that properties can hold data and have custom behavior when accessed or changed.

Knowing how properties work is essential because extension properties mimic property syntax but behave differently.

2

Foundation

Basics of Kotlin extensions

Concept: Learn how Kotlin lets you add new functions to existing classes using extensions.

Kotlin allows adding new functions to classes without modifying them, called extension functions. For example: fun String.lastChar(): Char = this[this.length - 1] val c = "Hello".lastChar() // 'o' This adds 'lastChar' to String, letting you call it like a normal method.

Result

You can add new behavior to classes externally, making code more flexible.

Understanding extension functions prepares you to grasp extension properties, which are similar but for properties.

3

Intermediate

Defining extension properties syntax

🤔Before reading on: do you think extension properties can store new data inside the class? Commit to yes or no.

Concept: Learn how to write extension properties and their limitations.

Extension properties look like regular properties but are defined outside the class: val String.firstChar: Char get() = this[0] You cannot add a backing field, so you must provide a getter (and optionally a setter for var). They compute values based on existing data.

Result

You can write properties that behave like class properties but only compute values, not store them.

Knowing that extension properties cannot store data clarifies their purpose as computed helpers, not state holders.

4

Intermediate

Using extension properties with var and val

🤔Before reading on: can extension properties be mutable (var) with backing fields? Commit to yes or no.

Concept: Understand how to create read-only and mutable extension properties and their constraints.

You can define extension properties as val (read-only) or var (mutable). However, var extension properties must have both getter and setter defined, and since no backing field exists, the setter must update something external: var StringBuilder.lastChar: Char get() = this[this.length - 1] set(value) { this.setCharAt(this.length - 1, value) } This changes the last character of the StringBuilder.

Result

You can create mutable extension properties but must handle storage or mutation externally.

Understanding this prevents confusion about data storage and shows how extension properties can modify objects indirectly.

5

Intermediate

Limitations of extension properties

Concept: Learn what extension properties cannot do compared to regular properties.

Extension properties cannot have backing fields, so they cannot store new data inside the class. They cannot override existing properties. Also, they do not actually modify the class's bytecode; they are resolved statically, meaning they don't support polymorphism.

Result

You know when extension properties are not suitable and avoid misuse.

Knowing these limits helps you choose the right tool and avoid bugs related to unexpected behavior.

6

Advanced

How extension properties work at runtime

🤔Before reading on: do you think extension properties are dynamically dispatched like normal properties? Commit to yes or no.

Concept: Understand the static resolution and how extension properties are compiled and called.

Extension properties are compiled as static methods with the receiver as a parameter. They are resolved at compile time, not runtime. This means if you have a variable typed as a superclass, the extension property of the subclass won't be called polymorphically. Example: open class A class B : A() val A.prop: String get() = "A" val B.prop: String get() = "B" val a: A = B() println(a.prop) // prints "A", not "B" This shows static dispatch.

Result

You understand why extension properties behave differently from member properties in inheritance.

Knowing static resolution prevents bugs when using extensions with inheritance and polymorphism.

7

Expert

Advanced use: backing properties and delegation

🤔Before reading on: can you create an extension property that stores data per instance using backing properties? Commit to yes or no.

Concept: Explore techniques to simulate stored extension properties using external storage or delegation.

Since extension properties cannot have backing fields, you can simulate storage by using external maps keyed by the instance: private val map = mutableMapOf() var Any.extensionData: String get() = map[this] ?: "" set(value) { map[this] = value } This lets you attach data to objects externally. Another approach is delegation with custom classes. However, this adds complexity and memory management concerns.

Result

You can effectively add stored properties externally but must manage lifecycle and memory carefully.

Understanding these advanced patterns reveals how to overcome language limits but also warns about complexity and pitfalls.

Under the Hood

Extension properties are compiled into static methods that take the receiver object as a parameter. The getter and setter are static functions outside the class. There is no backing field because the class bytecode is not modified. Calls to extension properties are resolved at compile time, so they do not support polymorphism or override behavior.

Why designed this way?

Kotlin's design keeps extension properties as syntactic sugar to add functionality without changing existing classes or their bytecode. This avoids breaking binary compatibility and keeps the language simple. Backing fields would require modifying class internals, which is not possible for external classes or interfaces.

┌───────────────┐       ┌─────────────────────┐
│   Caller      │──────▶│ Extension property   │
│ calls prop on │       │ static getter/setter │
│ receiver obj  │       └─────────────────────┘
└───────────────┘               ▲
                                │
                      Receiver object passed as parameter
                                │
                      ┌─────────────────────┐
                      │ Original class data  │
                      └─────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do extension properties add new fields to the class? Commit to yes or no.

Common Belief: Extension properties add new fields to store data inside the class.

Reality: Extension properties cannot add fields or store data inside the class; they only provide computed values via getters and setters.

Why it matters: Believing this leads to expecting stateful behavior, causing bugs when data is not stored or lost between accesses.

Quick: Are extension properties dynamically dispatched like member properties? Commit to yes or no.

Common Belief: Extension properties behave polymorphically and override base class properties.

Reality: Extension properties are resolved statically at compile time and do not support polymorphism or overriding.

Why it matters: This misconception causes confusion when subclass extension properties are not called through base class references.

Quick: Can extension properties be used to add mutable state easily? Commit to yes or no.

Common Belief: Extension properties can easily add mutable state to any class like normal properties.

Reality: Extension properties cannot store state internally; mutable behavior requires external storage or delegation.

Why it matters: Assuming easy mutable state leads to complicated workarounds and potential memory leaks.

Quick: Do extension properties modify the original class bytecode? Commit to yes or no.

Common Belief: Extension properties change the class itself by adding new members.

Reality: Extension properties do not modify the class bytecode; they are compiled as static helper methods.

Why it matters: Expecting class modification can cause misunderstanding of extension limitations and runtime behavior.

Expert Zone

1

Extension properties cannot access private members of the class because they are external and compiled as static methods.

2

Using extension properties with generic types can lead to unexpected behavior due to type erasure and static resolution.

3

Simulating stored extension properties with external maps requires careful memory management to avoid leaks, especially with long-lived objects.

When NOT to use

Avoid extension properties when you need to store state inside the class or require polymorphic behavior. Instead, use inheritance, delegation, or wrapper classes to add mutable properties or override behavior.

Production Patterns

In production, extension properties are often used to add computed read-only properties for convenience, such as formatting or derived values. They are also used in DSLs to create fluent APIs without modifying existing classes.

Connections

Extension functions

Extension properties build on the same mechanism as extension functions, adding property-like syntax.

Understanding extension functions helps grasp how extension properties provide similar external additions but with property semantics.

Decorator pattern (software design)

Extension properties provide a lightweight way to add behavior externally, similar to how decorators add responsibilities to objects.

Knowing the decorator pattern clarifies how extension properties enhance objects without inheritance or modification.

Labels and annotations in physical objects

Extension properties conceptually resemble adding labels to objects to provide extra information without changing the object itself.

This cross-domain connection helps appreciate the non-invasive nature of extension properties as metadata or computed tags.

Common Pitfalls

#1 Trying to store data in an extension property expecting it to persist per instance.

Wrong approach:

val String.myData: String = "default"
// expecting this to hold unique data per String instance

Correct approach:

val String.myData: String
get() = computeFromString(this)
// or use external map for storage

Root cause:

Misunderstanding that extension properties cannot have backing fields or store data inside the class.

#2 Expecting extension properties to override base class properties polymorphically.

Wrong approach:

open class A
val A.prop: String get() = "A"
class B : A()
val B.prop: String get() = "B"

val a: A = B()
println(a.prop) // expecting "B"

Correct approach:

Use member properties or override in subclasses instead of extension properties for polymorphism.

Root cause:

Not knowing extension properties are resolved statically, not dynamically.

#3 Defining var extension property without setter or with improper setter.

Wrong approach:

var String.prop: Int
get() = this.length
// missing setter

Correct approach:

var String.prop: Int
get() = this.length
set(value) { /* handle mutation externally */ }

Root cause:

Forgetting that var extension properties require both getter and setter because no backing field exists.

Key Takeaways

Extension properties let you add computed properties to existing classes without modifying them or adding storage.

They cannot store data internally and must provide getters (and setters for var) that compute or delegate behavior.

Extension properties are resolved statically at compile time, so they do not support polymorphism or overriding.

Advanced patterns can simulate stored extension properties using external maps but require careful memory management.

Understanding extension properties helps write cleaner, more flexible Kotlin code when working with third-party or built-in classes.