Amol Pawar

Generics in Kotlin provide a powerful way to write reusable and type-safe code. However, on the Java Virtual Machine (JVM), generics are subject to type erasure, meaning that the specific type arguments used for instances of a generic class are not preserved at runtime. This limitation has implications for runtime type checks and casts. But fear not! Kotlin provides a solution: reified type parameters. In this blog post, we’ll delve into the world of reified type parameters and explore how they enable us to access and manipulate type information at runtime.

Understanding Type Erasure in Kotlin Generics

Generics in Kotlin are implemented using type erasure on the JVM. This means that the specific type arguments used for instances of a generic class are not preserved at runtime. In this section, we’ll explore the practical consequences of type erasure in Kotlin and learn how you can overcome its limitations by declaring a function as inline.

By declaring a function as inline, you can prevent the erasure of its type arguments. In Kotlin, this is achieved by using reified type parameters. Reified type parameters allow you to access and manipulate the actual type information of the generic arguments at runtime.

In simpler terms, when you mark a function as inline with a reified type parameter, you can retrieve and work with the specific types used as arguments when calling that function.

Now, let’s look at some examples to better understand the concept of reified type parameters and their usefulness.

Generics at runtime: type checks and casts

Generics in Kotlin, similar to Java, are erased at runtime. This means that the type arguments used to create an instance of a generic class are not preserved at runtime. For example, if you create a List<String> and put strings into it, at runtime, you will only see it as a List. You won’t be able to identify the specific type of elements the list was intended to contain. However, the compiler ensures that only elements of the correct type are stored in the list based on the type arguments provided during compilation.

Let’s consider the following code:

val list1: List<String> = listOf("a", "b")
val list2: List<Int> = listOf(1, 2, 3)

Even though the compiler recognizes list1 and list2 as distinct types, at execution time, they appear the same. However, you can generally rely on List<String> to contain only strings and List<Int> to contain only integers because the compiler knows the type arguments and enforces type safety. It is possible to deceive the compiler using type casts or Java raw types, but it requires a deliberate effort.

When it comes to checking the type information at runtime, the erased type information poses some limitations. You cannot directly check if a value is an instance of a specific erased type with type arguments. For example, the following code won’t compile:

if (value is List<String>) { ... } // Error: Cannot check for instance of erased type

Even though you can determine at runtime that value is a List, you cannot determine whether it’s a list of strings, persons, or some other type. That information is erased.

Note that erasing generic type information has its benefits: the overall amount of memory used by your application is smaller; because less type information needs to be saved in memory.

As we stated earlier, Kotlin doesn’t let you use a generic type without specifying type arguments. Thus you may wonder how to check that the value is a list, rather than a set or another object

To check if a value is a List without specifying its type argument, you can use the star projection syntax:

if (value is List<*>) { ... }

By using List<*>, you’re essentially treating it as a type with unknown type arguments, similar to Java’s List<?>. In this case, you can determine that the value is a List, but you won’t have any information about its element type.

Note that you can still use normal generic types in as and as? casts. However, these casts won’t fail if the class has the correct base type but a wrong type argument because the type argument is not known at runtime. The compiler will emit an “unchecked cast” warning for such casts. It’s important to understand that it’s only a warning, and you can still use the value as if it had the necessary type.

Here’s an example of using as? cast with a warning:

fun printSum(c: Collection<*>) {
    val intList =
        c as? List<Int> // Warning here. Unchecked cast: List<*> to List<Int>
         ?: throw IllegalArgumentException("List is expected")
    println(intList.sum())
}

This code defines a function called printSum that takes a collection (c) as a parameter. Within the function, a cast is performed using the as? operator, attempting to cast c as a List<Int>. If the cast succeeds, the resulting value is assigned to the variable intList. However, if the cast fails (i.e., c is not a List<Int>), the as? operator returns null, and the code throws an IllegalArgumentException with the message “List is expected”. Finally, the sum of the integers in intList is printed.

Let’s see how this function behaves when called with different inputs:

printSum(listOf(1, 2, 3))  // o/p - 6

When called with a list of integers, the function works as expected. The sum of the integers is calculated and printed.

Now let’s change the input to a set:

printSum(setOf(1, 2, 3))   // o/p - IllegalArgumentException: List is expected

When called with a set of integers, the function throws an IllegalArgumentException because the input is not a List. The as? cast fails, resulting in a null value, and the IllegalArgumentException is thrown.

Now we pass String as input:

printSum(listOf("a", "b", "c"))  // o/p - ClassCastException: String cannot be cast to Number

When called with a list of strings, the function successfully casts the list to a List<Int>, despite the wrong type argument. However, during the execution of intList.sum(), a ClassCastException occurs. This happens because the function tries to treat the strings as numbers, resulting in a runtime error.

The code examples above demonstrate that type casts (as and as?) in Kotlin may lead to runtime exceptions if the casted type and the actual type are incompatible. The compiler emits an “unchecked cast” warning to notify you about this potential risk. It’s important to understand the meaning of these warnings and be cautious when using type casts.

The code snippet below shows an alternative approach using an is check:

fun printSum(c: Collection<*>) {
    val intList =
        c as? List<Int> // Warning here. Unchecked cast: List<*> to List<Int>
         ?: throw IllegalArgumentException("List is expected")
    println(intList.sum())
}

In this example, the printSum function takes a Collection<Int> as a parameter. Using the is operator, it checks if c is a List<Int>. If the check succeeds, the sum of the integers in the list is printed. This approach is possible because the compiler knows at compile time that c is a collection of integers.

So, Kotlin’s compiler helps you identify potentially dangerous type checks (forbidding is checks) and emits warnings for type casts (as and as?) that may cause issues at runtime. Understanding these warnings and knowing which operations are safe is essential when working with type casts in Kotlin.

Power of Reified Type Parameters in Inline Functions

In Kotlin, generics are typically erased at runtime, which means that you can’t determine the type arguments used when an instance of a generic class is created or when a generic function is called. However, there is an exception to this limitation when it comes to inline functions. By marking a function as inline, you can make its type parameters reified, which allows you to refer to the actual type arguments at runtime.

Let’s take a look at an example to illustrate this. Suppose we have a generic function called isA that checks if a given value is an instance of a specific type T:

fun <T> isA(value: Any) = value is T

If we try to call this function with a specific type argument, like isA<String>("abc"), we would encounter an error because the type argument T is erased at runtime.

However, if we modify the function to be inline and mark the type parameter as reified, like this:

inline fun <reified T> isA(value: Any) = value is T

Now we can call isA<String>("abc") and isA<String>(123) without any errors. The reified type parameter allows us to check whether the value is an instance of T at runtime. In the first example, the output will be true because "abc" is indeed a String, while in the second example, the output will be false because 123 is not a String.

Another practical use of reified type parameters is demonstrated by the filterIsInstance function from the Kotlin standard library. This function takes a collection and selects instances of a specified class, returning only those instances. For example:

val items = listOf("one", 2, "three")
println(items.filterIsInstance<String>())

In this case, we specify <String> as the type argument for filterIsInstance, indicating that we are interested in selecting only strings from the items list. The function’s return type is automatically inferred as List<String>, and the output will be [one, three].

Here’s a simplified version of the filterIsInstance function’s declaration from the Kotlin standard library:

inline fun <reified T> Iterable<*>.filterIsInstance(): List<T> {
    val destination = mutableListOf<T>()
    for (element in this) {
        if (element is T) {
            destination.add(element)
        }
    }
    return destination
}

Before coming to this code explanation, have you ever thought, Why reification works for inline functions only? How does this work? Why are you allowed to write element is T in an inline function but not in a regular class or function? Let’s see the answers to all these questions:

Reification works for inline functions because the compiler inserts the bytecode implementing the inline function directly at every place where it is called. This means that the compiler knows the exact type used as the type argument in each specific call to the inline function.

When you call an inline function with a reified type parameter, the compiler can generate a bytecode that references the specific class used as the type argument for that particular call. For example, in the case of the filterIsInstance<String>() call, the generated code would be equivalent to:

for (element in this) {
    if (element is String) {
        destination.add(element)
    }
}

The generated bytecode references the specific String class, not a type parameter, so it is not affected by the type-argument erasure that occurs at runtime. This allows the reified type parameter to be used for type checks and other operations at runtime.

It’s important to note that inline functions with reified type parameters cannot be called from Java code. Regular inline functions are accessible to Java as regular functions, meaning they can be called but are not inlined. However, functions with reified type parameters require additional processing to substitute the type argument values into the bytecode, and therefore they must always be inlined. This makes it impossible to call them in a regular way, as Java code does not support this mechanism.

Also, one more thing to note is that an inline function can have multiple reified type parameters and can also have non-reified type parameters alongside the reified ones. It’s important to keep in mind that marking a function as inline does not necessarily provide performance benefits in all cases. If the function becomes large, it’s recommended to extract the code that doesn’t depend on reified type parameters into separate non-inline functions for better performance.

Practical use cases of reified type parameters

Reified type parameters can be especially useful when working with APIs that expect parameters of type java.lang.Class. Let\’s explore two examples to demonstrate how reified type parameters simplify such scenarios.

Example 1

ServiceLoader The ServiceLoader API from the JDK is an example of an API that takes a java.lang.Class representing an interface or abstract class and returns an instance of a service class implementing that interface. Traditionally, in Kotlin, you would use the following syntax to load a service:

val serviceImpl = ServiceLoader.load(Service::class.java)

However, using a function with a reified type parameter, we can make this code shorter and more readable:

val serviceImpl = loadService<Service>()

To define the loadService function, we use the inline modifier and a reified type parameter:

inline fun <reified T> loadService(): T {
    return ServiceLoader.load(T::class.java)
}

Here, T::class.java retrieves the java.lang.Class corresponding to the class specified as the type parameter, allowing us to use it as needed. This approach simplifies the code by specifying the class as a type argument, which is shorter and easier to read compared to ::class.java syntax.

Example 2

Simplifying startActivity in Android In Android development, when launching activities, instead of passing the class of the activity as a java.lang.Class, you can use a reified type parameter to make the code more concise. For instance:

inline fun <reified T : Activity> Context.startActivity() {
    val intent = Intent(this, T::class.java)
    startActivity(intent)
}

With this inline function, you can start an activity by specifying the activity class as a type argument:

startActivity<DetailActivity>()

This simplifies the code by eliminating the need to pass the activity class as a java.lang.Class instance explicitly.

Reified type parameters allow us to work with class references directly, making the code more readable and concise. They are particularly useful in scenarios where APIs expect java.lang.Class parameters, such as ServiceLoader in Java or starting activities in Android.

Restrictions on Reified Type Parameters

Reified Type parameters in Kotlin have certain restrictions that you need to be aware of. Some of these restrictions are inherent to the concept itself, while others are determined by the implementation of Kotlin and may change in future Kotlin versions. Here’s a summary of how you can use reified type parameters and what you cannot do:

You can use a reified type parameter in the following ways:

Type checks and casts (is, !is, as, as?)

Reified type parameters can be used in type checks and casts. You can check if an object is of a specific type or perform a type cast using the reified type parameter. Here’s an example:

inline fun <reified T> checkType(obj: Any) {
    if (obj is T) {
        println("Object is of type T")
    } else {
        println("Object is not of type T")
    }
    
    val castedObj = obj as? T
    // Perform operations with the casted object
}

Kotlin reflection APIs (::class)

Reified type parameters can be used with Kotlin reflection APIs, such as ::class, to access runtime information about the type. It allows you to retrieve the KClass object representing the type parameter. Here’s an example:

inline fun <reified T> getTypeInformation() {
    val typeInfo = T::class
    println("Type information: $typeInfo")
}

Getting the corresponding java.lang.Class (::class.java)

Reified type parameters can also be used to obtain the corresponding java.lang.Class object of the type using the ::class.java syntax. This can be useful when interoperating with Java APIs that require Class objects. Here’s an example:

inline fun <reified T> getJavaClass() {
    val javaClass = T::class.java
    println("Java class: $javaClass")
}

Using reified type parameter as a type argument when calling other functions

Reified type parameters can be used as type arguments when calling other functions. This allows you to propagate the type information to other functions without losing it due to type erasure. Here’s an example:

inline fun <reified T> processList(list: List<T>) {
    // Process the list of type T
    for (item in list) {
        // ...
    }
}

fun main() {
    val myList = listOf("Hello", "World")
    processList<String>(myList)
}

These examples demonstrate the various ways in which reified type parameters can be utilized in Kotlin, including type checks, reflection APIs, obtaining java.lang.Class, and passing the type information to other functions as type arguments.

However, there are certain things you cannot do with reified type parameters:

Creating new instances of the class specified as a type parameter

Reified type parameters cannot be used to create new instances of the class directly. You can only access the type information using reified type parameters. To create new instances, you would need to use other means such as reflection or factory methods. Here’s an example:

inline fun <reified T> createInstance(): T {
    // Error: Cannot create an instance of the type parameter T
    return T()
}

Calling methods on the companion object of the type parameter class

Reified type parameters cannot directly access the companion object of the type parameter class. However, you can access the class itself using T::class syntax. To call methods on the companion object, you would need to access it through the class reference. Here’s an example:

inline fun <reified T> callCompanionMethod(): String {
    // Error: Cannot access the companion object of the type parameter T
    return T.Companion.someMethod()
}

Using a non-reified type parameter as a type argument

When calling a function with a reified type parameter, you cannot use a non-reified type parameter as a type argument. Reified type parameters can only be used as type arguments themselves. Here’s an example:

inline fun <reified T> reifiedFunction() {
    // Error: Non-reified type parameter cannot be used as a type argument
    anotherFunction<T>()
}

fun <T> anotherFunction() {
    // ...
}

Marking type parameters of classes, properties, or non-inline functions as reified

Reified type parameters can only be used in inline functions. You cannot mark type parameters of classes, properties, or non-inline functions as reified. Reified type parameters are limited to inline functions. Here’s an example:

class MyClass<T> {  // Error: Type parameter cannot be marked as reified
    // ...
}

val <T> List<T>.property: T  // Error: Type parameter cannot be marked as reified
    get() = TODO()

fun <T> nonInlineFunction() {  // Error: Type parameter cannot be marked as reified
    // ...
}

These examples illustrate the restrictions on reified type parameters in Kotlin. By understanding these limitations, you can use reified type parameters effectively in inline functions while keeping in mind their specific usage scenarios.

Conclusion

Reified type parameters in Kotlin offer a powerful tool for overcoming the limitations of type erasure at runtime. By utilizing reified type parameters in inline functions, developers can access and manipulate precise type information, enabling type checks, casts, and interaction with reflection APIs. Understanding the benefits and restrictions of reified type parameters empowers Kotlin developers to write more expressive, type-safe, and concise code.

By embracing reified type parameters, Kotlin programmers can unleash the full potential of generics and enhance their runtime type-related operations. Start utilizing reified type parameters today and unlock a world of type-aware programming in Kotlin!

Kotlin, a modern and versatile programming language, offers various features to enhance developer productivity. One such powerful feature is function types, which enable you to treat functions as first-class citizens in your code. In this blog post, we will delve into function types in Kotlin, understand their types, explore their usage, and provide examples to solidify our understanding. So let’s dive in!

Recap: Higher-Order Functions

In Kotlin, a higher-order function is a function that can accept a lambda expression or a function reference as an argument or can return a lambda expression or a function reference. It allows functions to be treated as values and enables flexible and concise coding.

Let’s take the example of the filter function from the standard library, which takes a predicate function as an argument and is, therefore, a higher-order function:

list.filter { x > 0 }

Function types

In Kotlin, you can declare variables with function types. This means that the variables can hold references to functions. Let’s take a look at an example:

val sum: (Int, Int) -> Int = { x, y -> x + y }  // Function that takes two Int parameters and returns an Int value
val action: () -> Unit = { println(42) }        // Function that takes no arguments and doesn’t return a value

In this code, we have two variables: sum and action. The type of sum is a function that takes two Int parameters and returns an Int. The type of action is a function that takes no parameters and returns Unit, which represents a lack of meaningful value.

What are Function Types?

Function types allow you to treat functions as values. Just like any other variable, you can assign functions to variables, pass them as parameters to other functions, and even return them from functions. This feature provides flexibility and enables you to write more concise and expressive code.

Syntax

To declare a function type, you put the function parameter types in parentheses, followed by an arrow, and the return type of the function. In the above diagram, (Int, String) -> Unit specifies a function that takes Int and String parameters and returns a Unit.

The Unit type is used to indicate that a function doesn’t return a meaningful value. In regular function declarations, you can omit the Unit return type, but in function type declarations, it is always required. So, you can’t omit a Unit in this context.

val sum: (Int, Int) -> Int = { x, y -> x + y }

In the lambda expression { x, y -> x + y }, you might notice that the types of the parameters x and y are omitted. This is because the types are already specified in the function type declaration, so there’s no need to repeat them in the lambda itself.

You can also make the return type of a function type nullable by using the? symbol. For example:

var canReturnNull: (Int, Int) -> Int? = { null }

In this case, the function type (Int, Int) -> Int? represents a function that takes two Int parameters and returns an Int that can be nullable. This means the function can return either an Int value or null.

Furthermore, you can declare a nullable variable of a function type by enclosing the entire function type definition in parentheses and placing the question mark after the parentheses. For example:

var funOrNull: ((Int, Int) -> Int)? = null

Here, ((Int, Int) -> Int)? represents a nullable variable of a function type. The entire function type definition is enclosed in parentheses, and the question mark indicates that the variable itself is nullable.

It’s important to note the distinction between a function type with a nullable return type ((Int, Int) -> Int?) and a nullable variable of a function type (((Int, Int) -> Int)?). Omitting the parentheses will result in different meanings, so be cautious when specifying nullable function types.

Parameter names of function types

In Kotlin, you have the option to specify names for the parameters of a function type. This can improve the readability of your code and can be helpful for code completion in the IDE.

Here’s an example that demonstrates specifying parameter names in a function type:

fun performRequest(url: String, callback: (code: Int, content: String) -> Unit) {
    /* ... */
}

In this code, the performRequest function takes two parameters: url of type String and callback of type (code: Int, content: String) -> Unit. The callback parameter is a function type that expects two parameters named code and content, both of type Int and String respectively. The function type represents a callback function that will be invoked when the request is completed.

When you call the performRequest function, you can provide a lambda expression as the argument for the callback parameter. The lambda can use any parameter names you prefer, regardless of the names specified in the function type declaration. For example:

val url = "https://blog.softaai.com"
performRequest(url) { code, content ->
    // Code that uses the parameters 'code' and 'content'
}

performRequest(url) { code, page ->
    // Code that uses the parameters 'code' and 'page'
}

In the above examples, we pass a lambda expression to the performRequest function. Inside the lambda, we can choose different names for the parameters (code and content in the first example, and code and page in the second example). These parameter names in the lambda expression do not need to match the names specified in the function type declaration.

Although the parameter names don’t affect type matching, using descriptive names can make your code more readable and understandable. Additionally, modern IDEs can utilize these parameter names for code completion, making it easier for you to write your code accurately.

Calling functions passed as arguments

In Kotlin, you can call functions that are passed as arguments to other functions. Let’s explore a couple of examples to understand how this works.

First, let’s consider the twoAndThree function, which takes another function as an argument and performs an arbitrary operation on the numbers 2 and 3:

fun twoAndThree(operation: (Int, Int) -> Int) {
    val result = operation(2, 3)
    println("The result is $result")
}

In this example, the twoAndThree function accepts a function called operation, which has a function type (Int, Int) -> Int. This means the operation function takes two Int parameters and returns an Int. Inside the twoAndThree function, the operation function is called with arguments 2 and 3, and the result is printed.

To call the twoAndThree function and pass a function as an argument, you can use a lambda expression. For example:

twoAndThree { a, b -> a + b }

In this case, we pass a lambda expression that adds two numbers (a + b). The lambda matches the function type (Int, Int) -> Int because it takes two Int parameters and returns an Int. The result of the addition, 5, is printed by the twoAndThree function.

Similarly, you can pass a different lambda expression to achieve a different operation:

twoAndThree { a, b -> a * b }

Here, the lambda multiplies the two numbers (a * b), and the result, 6, is printed.

The syntax for calling a function passed as an argument is the same as calling a regular function. You use parentheses after the function name and provide the necessary arguments inside the parentheses.

Now, let’s consider another example: reimplementing the filter function from the standard library. The filter function takes a predicate as a parameter. The predicate is a function that takes a character and returns a Boolean result. The implementation checks whether each character satisfies the predicate and adds it to a StringBuilder if it does.

To reimplement the filter function for strings, let’s consider the following implementation:

fun String.filter(predicate: (Char) -> Boolean): String {
    val sb = StringBuilder()
    for (index in 0 until length) {
        val element = get(index)
        if (predicate(element))
            sb.append(element)
    }
    return sb.toString()
}

In this implementation, the filter function is an extension function on the String class. It takes a predicate parameter, which is a function that takes a Char parameter and returns a Boolean.

Inside the function, a StringBuilder is created to store the filtered characters. The function iterates over each character of the string using the for loop and checks if the character satisfies the given predicate. If the predicate returns true for a character, it is appended to the StringBuilder.

Finally, the StringBuilder is converted to a string using the toString() function and returned as the result.

Here’s an example of how you can use the filter function:

println("softAai Apps".filter { it in 'A'..'Z' })

In this case, the input string is "softAai Apps", and the predicate checks if each character is within the range from 'A' to 'Z'. The filtered result, which only contains the uppercase alphabetic characters, is printed as "AA".

The filter function implementation is straightforward. It enables you to filter characters from a string based on a given predicate, providing a more convenient and readable way to perform such operations.

By using higher-order functions and passing functions as arguments, you can create flexible and reusable code that can perform different operations based on the provided functions.

Default and null values for parameters with function types

When declaring a parameter of a function type, you can specify a default value for it. This can be useful when you want to provide a default behavior for the function if the caller doesn’t provide a specific implementation. Here’s an example:

fun <T> printCollection(collection: Collection<T>, transform: (T) -> String = { it.toString() }) {
    for (element in collection) {
        println(transform(element))
    }
}

In this example, the printCollection function takes a collection parameter of type Collection<T> and a transform parameter of function type (T) -> String. The transform parameter has a default value defined as a lambda expression { it.toString() }, which uses the toString() method to convert each element of the collection to a string.

You can call the printCollection function in different ways:

val numbers = listOf(1, 2, 3, 4, 5)

// Omitting the transform parameter to use the default behavior
printCollection(numbers)

// Passing a lambda as the transform parameter
printCollection(numbers) { "Number: $it" }

// Passing the transform parameter as a named argument
printCollection(numbers, transform = { "Value: $it" })

In the first example, we omit the transform parameter, so the default behavior using toString() will be used to convert each element.

In the second example, we pass a lambda expression { "Number: $it" } as the transform parameter. This lambda defines a custom behavior to transform each element of the collection.

In the third example, we explicitly pass the transform parameter as a named argument, providing a different lambda expression { "Value: $it" } to customize the transformation.

Another option is to declare a parameter of a nullable function type. However, directly calling a function passed in such a parameter is not allowed because it could potentially lead to null pointer exceptions. To handle this, you can check for null explicitly or use the safe-call syntax callback?.invoke(). Here’s an example:

fun performAction(callback: (() -> Unit)?) {
    callback?.invoke()
}

In this example, the performAction function takes a nullable function type parameter callback of type (() -> Unit)?. Inside the function, we can use the safe-call syntax callback?.invoke() to invoke the function only if it is not null.

Function Types with Generic Parameters

Kotlin allows you to define function types with generic parameters. This provides flexibility when working with functions that can operate on different types.

fun <T> processList(list: List<T>, operation: (T) -> Unit) {
    for (item in list) {
        operation(item)
    }
}

val numbers = listOf(1, 2, 3, 4, 5)
processList(numbers) { println(it) } // Prints each number in the list

In the above example, the processList function takes a list of generic type T and a function type (T) -> Unit as parameters. The operation function is called for each item in the list and can perform any desired operation.

Now you know how to write functions that take functions as arguments, including how to provide default values for function parameters and handle nullable function types. This allows you to create more flexible and customizable functions in Kotlin.

Returning functions from functions

Returning functions from functions allows you to dynamically choose and provide different logic based on certain conditions or states. This can be useful in scenarios where the behavior of a program needs to adapt to different situations.

For example, let’s consider a shipping cost calculation scenario. The shipping cost may vary depending on the chosen delivery method. We can define a function called getShippingCostCalculator that takes the delivery parameter of type Delivery (an enum class representing different delivery options) and returns a function of type (Order) -> Double. The returned function calculates the shipping cost based on the selected delivery method.

Here’s an example implementation:

enum class Delivery { STANDARD, EXPEDITED }

class Order(val itemCount: Int)

fun getShippingCostCalculator(delivery: Delivery): (Order) -> Double {   // Declares a function that returns a function
    if (delivery == Delivery.EXPEDITED) {
        return { order -> 6 + 2.1 * order.itemCount }  // Returns lambdas from the function
    }
    return { order -> 1.2 * order.itemCount }     // Returns lambdas from the function
}

In this example, when getShippingCostCalculator is called with Delivery.EXPEDITED, it returns a function that takes an Order parameter and calculates the shipping cost as 6 + 2.1 * order.itemCount. For any other delivery option, it returns a different function that calculates the shipping cost as 1.2 * order.itemCount.

You can use the returned function to calculate the shipping cost for a specific order. Here’s an example of usage:

val calculator = getShippingCostCalculator(Delivery.EXPEDITED)  // Stores the returned function in a variable
println("Shipping costs ${calculator(Order(3))}")   // Invokes the returned function

In this code, we obtain the calculator function by calling getShippingCostCalculator with Delivery.EXPEDITED. Then, we pass an Order object with itemCount as 3 to the calculator function, which calculates and returns the shipping cost as 12.3. Finally, we print the shipping cost.

Let’s consider one more scenario where returning functions from functions is useful.

Suppose you’re working on a GUI contact-management application, and you need to determine which contacts should be displayed based on the state of the user interface (UI). You can define a function called getContactFilter that takes a UI state as a parameter and returns a function of type (Contact) -> Boolean. The returned function will determine whether a contact should be displayed or not based on the UI state.

Here’s an example implementation:

data class Contact(val name: String, val isFavorite: Boolean)

enum class UIState { ALL, FAVORITES }

fun getContactFilter(uiState: UIState): (Contact) -> Boolean {  // Declares a function that returns a function
    return when (uiState) {
        UIState.ALL -> { true } // Display all contacts
        UIState.FAVORITES -> { contact -> contact.isFavorite } // Display only favorite contacts
    }
}

In this example, getContactFilter takes a UIState parameter and returns a function of type (Contact) -> Boolean. The returned function determines whether a contact should be displayed or not based on the UI state. If the UI state is UIState.ALL, the returned function always returns true, indicating that all contacts should be displayed. If the UI state is UIState.FAVORITES, the returned function checks the isFavorite property of the contact and returns its value, indicating whether the contact is a favorite or not.

You can use the returned function to filter the contacts based on the UI state. Here’s an example usage:

val filter = getContactFilter(UIState.FAVORITES)
val contacts = listOf(
    Contact("amol pawar", true),
    Contact("atul tele", false),
    Contact("akshay pawal", true)
)
val filteredContacts = contacts.filter(filter)
println("Filtered Contacts:")
filteredContacts.forEach { println(it.name) }

In this code, we obtain the filter function by calling getContactFilter with UIState.FAVORITES. Then, we have a list of contacts, and we use the filter function to filter the contacts based on the UI state. The filtered contacts, in this case, are the contacts that are marked as favorites. Finally, we print the names of the filtered contacts.

Returning functions from functions allows you to dynamically select and apply different logic based on conditions or states, providing flexibility and customization in your code.

Using function types from Java

Under the hood, function types are declared as regular interfaces: a variable of a function type is an implementation of a FunctionN interface. The Kotlin standard library defines a series of interfaces, corresponding to different numbers of function arguments: Function0 (this function takes no arguments), Function1 (this function takes one argument), and so on. Each interface defines a single invoke method, and calling it will execute the function. A variable of a function type is an instance of a class implementing the corresponding FunctionN interface, with the invoke method containing the body of the lambda.

Kotlin functions that use function types can be called easily from Java. Java 8 lambdas are automatically converted to values of function types:

/* Kotlin declaration */
fun processTheAnswer(f: (Int) -> Int) {
    println(f(42))
}

// Java
processTheAnswer(number -> number + 1);  // output : 43

In this case, the processTheAnswer function in Kotlin takes a function type (Int) -> Int as a parameter. In Java, you can pass a lambda expression number -> number + 1 as an argument, and it will be automatically converted to the corresponding function type.

What about older Java versions?

If you are using an older version of Java that doesn’t support lambdas, you can pass an instance of an anonymous class that implements the invoke method from the corresponding function interface. Here’s an example:

// Java
processTheAnswer(new Function1<Integer, Integer>() {    // Uses the Kotlin function type from Java code (prior to Java 8)
    @Override
    public Integer invoke(Integer number) {
        System.out.println(number);
        return number + 1;
    }
});

In this Java example, we create an anonymous class that implements the Function1 interface. We override the invoke method, which corresponds to the function body in Kotlin, and provide the desired implementation.

What about Extention Functions?

In Java, you can easily use extension functions from the Kotlin standard library that expect lambdas as arguments. Note, however, that they don’t look as nice as in Kotlin — you have to pass a receiver object as a first argument explicitly. Here’s an example:

// Java
List<String> strings = new ArrayList<>();
strings.add("42");
CollectionsKt.forEach(strings, s -> {
    System.out.println(s);
    return Unit.INSTANCE;
});

In this Java example, we use the CollectionsKt.forEach extension function from the Kotlin standard library. We pass a lambda expression s -> { ... } as an argument. Inside the lambda, we can perform the desired operations. Note that in Java, you need to explicitly return Unit.INSTANCE to match the Kotlin requirement of returning Unit.

It’s important to remember that in Java, functions or lambdas can return Unit. However, since Unit has a value in Kotlin, you need to explicitly return it. Additionally, you cannot directly pass a lambda that returns void as an argument of a function type that expects Unit as the return type.

Overall, while using function types and lambdas from Kotlin in Java may require some adjustments in syntax, it is still possible to utilize Kotlin’s higher-order functions and achieve the desired functionality.

Removing duplication through lambdas

In Kotlin, lambdas are anonymous functions that can be treated as values. They allow you to define blocks of code that can be passed around and executed later. This flexibility enables us to write more concise and reusable code.

Suppose you have a scenario where you need to perform similar operations on different elements of a collection. Without lambdas, you might end up writing repetitive code for each element, resulting in duplication. However, by utilizing lambdas, you can extract the common behavior and eliminate duplication.

To illustrate this concept, let’s consider an example involving website visit data. We have a class called SiteVisit that represents a visit to a website. Each visit has properties like path (the visited URL), duration (time spent on the page), and os (operating system used by the visitor). The os property is an enum called OS, representing different operating systems.

data class SiteVisit(
    val path: String,
    val duration: Double,
    val os: OS
)

enum class OS { WINDOWS, LINUX, MAC, IOS, ANDROID }

Now, let’s say we have a list of SiteVisit objects called log, which contains information about various visits to the website.

val log = listOf(
    SiteVisit("/", 34.0, OS.WINDOWS),
    SiteVisit("/", 22.0, OS.MAC),
    SiteVisit("/login", 12.0, OS.WINDOWS),
    SiteVisit("/signup", 8.0, OS.IOS),
    SiteVisit("/", 16.3, OS.ANDROID)
)

Our goal is to calculate the average duration of visits from Windows machines. We can achieve this by filtering the visits based on the operating system, mapping the durations, and then calculating the average using the average function.

val averageWindowsDuration = log
    .filter { it.os == OS.WINDOWS }
    .map(SiteVisit::duration)
    .average()

println(averageWindowsDuration) // Output: 23.0

In this example, we used the lambda expression { it.os == OS.WINDOWS } as a filter to select only the visits with the Windows operating system. Then, we used the map function to extract the durations of those visits. Finally, the average function calculated the average duration.

Now, let’s say we want to calculate the average duration for visits from Mac users as well. Without using lambdas, we would need to write similar code again, resulting in duplication. However, we can avoid this duplication by extracting the common behavior into a function and parameterizing it.

We define an extension function called averageDurationFor on the List<SiteVisit> class, which takes an os parameter representing the operating system. Inside the function, we filter the visits based on the given operating system, map the durations, and calculate the average.

fun List<SiteVisit>.averageDurationFor(os: OS) =
    filter { it.os == os }
        .map(SiteVisit::duration)
        .average()

With this function in place, we can now calculate the average duration for both Windows and Mac visits without duplicating the code.

println(log.averageDurationFor(OS.WINDOWS)) // Output: 23.0
println(log.averageDurationFor(OS.MAC)) // Output: 22.0

By parameterizing the behavior that varies (in this case, the operating system), we eliminated duplication and made the code more reusable and maintainable.

However, there are situations where a simple parameter is not sufficient to capture the complexity of the condition we want to apply. For example, if we want to calculate the average duration for visits from mobile platforms (iOS and Android), a single parameter representing the operating system won’t be enough. In such cases, lambdas provide a powerful solution.

We can modify our averageDurationFor function to take a lambda expression as a parameter. This lambda expression represents a condition that needs to be fulfilled for a visit to be included in the calculation.

fun List<SiteVisit>.averageDurationFor(predicate: (SiteVisit) -> Boolean) =
    filter(predicate)
        .map(SiteVisit::duration)
        .average()

Now, we can use this enhanced averageDurationFor function to calculate the average duration based on more complex conditions. For example, finding the average duration for visits from Android and iOS users:

println(log.averageDurationFor { it.os in setOf(OS.ANDROID, OS.IOS) }) // Output: 12.15

In this case, we passed a lambda expression { it.os in setOf(OS.ANDROID, OS.IOS) } to the averageDurationFor function. This lambda expression represents the condition that checks if the operating system is either Android or iOS.

Similarly, we can use Lambdas to perform more intricate queries, such as finding the average duration of visits to the signup page from iOS users:

println(log.averageDurationFor { it.os == OS.IOS && it.path == "/signup" }) // Output: 8.0

Here, we provided a lambda expression { it.os == OS.IOS && it.path == "/signup" } to specify the condition that includes only the visits from iOS users to the “/signup” page.

By using lambdas and function types, we can eliminate code duplication and extract both the repeated data and behavior into reusable functions. Lambdas allow us to write more expressive and concise code, making our programs easier to understand and maintain.

Function types and lambdas not only help eliminate code duplication but also provide a flexible and concise way to define different strategies or behaviors within your code. Instead of creating multiple classes or interfaces for each strategy, you can directly pass lambda expressions as different strategies, simplifying your code and making it more expressive.

Conclusion

Function types in Kotlin provide a powerful way to work with functions as first-class citizens. They enable you to pass functions as parameters, return them from functions, and even assign them to variables. This flexibility allows for concise and expressive code, making Kotlin a great language for functional programming paradigms. By understanding the various aspects of function types and exploring practical examples, you can leverage this feature to write more efficient and maintainable code. So go ahead, harness the power of function types in Kotlin, and take your programming skills to the next level!

Kotlin offers various powerful features to make code concise and efficient. One such feature is delegation, which allows you to delegate the implementation of properties or functions to another object. This concept of delegation plays a crucial role in achieving code reuse, separation of concerns, and enhancing the readability and maintainability of your code. In this blog, we will explore Kotlin delegation and delve into the details of delegated properties.

Delegated properties allow you to leverage the power of trusted helper objects called delegates. These delegates handle complex tasks, freeing up your properties to focus on their core responsibilities. From database tables to browser sessions and maps, the possibilities are endless.

Join me as we embark on this thrilling journey, exploring the art of delegation and unlocking the true potential of Kotlin delegation properties. Get ready to witness the magic as your properties become extraordinary with just a touch of delegation!

Understanding Kotlin Delegation

Delegation in programming is a design pattern where an object, known as the delegate, is given the responsibility to handle certain tasks or operations on behalf of another object, known as the delegator. The delegator object delegates the work to the delegate object, which performs the task and returns the result to the delegator.

Let’s use a real-life example to understand delegation in Kotlin. Consider a scenario where you have a restaurant with a customer, a waiter, and a chef. The customer wants to order a meal, and the waiter is responsible for taking the order and delivering it to the chef. The chef prepares the meal and hands it back to the waiter, who serves it to the customer.

In this example, the customer is the delegator, and the waiter is the delegate. The customer delegates the task of taking the order and delivering it to the waiter. The waiter performs these tasks on behalf of the customer and then delegates the task of preparing the meal to the chef. Finally, the waiter serves the meal back to the customer.

Let’s take one more example, consider a Car class that needs to perform some operations related to engine management. Instead of implementing those operations directly in the Car class, we can delegate them to an Engine object. This way, the Car class can focus on its core functionality, while the Engine object handles engine-related tasks.

Delegation provides benefits such as modularity, maintainability, and flexibility in designing software systems.

Overview of the Delegation Pattern

The delegation pattern is a design pattern where an object delegates some or all of its responsibilities to another object. Instead of inheriting behavior, an object maintains a reference to another object and forwards method calls to it. This promotes composition over inheritance and provides greater flexibility in reusing and combining behaviors from different objects.

In Kotlin, the delegation pattern is built into the language, making it easy and convenient to implement. With the by keyword, Kotlin allows a class to implement an interface by delegating all of its public members to a specified object. Let’s dive into the details and see how it works.

Basic Usage of Delegation in Kotlin

To understand the basic usage of delegation in Kotlin, let’s consider a simple example. Assume we have an interface called Base with a single function print()

interface Base {
    fun print()
}

Next, we define a class BaseImpl that implements the Base interface. It has a constructor parameter x of type Int and provides an implementation for the print() function.

class BaseImpl(val x: Int) : Base {
    override fun print() {
        println(x)
    }
}

Now, we want to create a class called Derived that also implements the Base interface. Instead of implementing the print() function directly, we can delegate it to an instance of the Base interface. We achieve this by using the by keyword followed by the object reference in the class declaration.

class Derived(b: Base) : Base by b

In this example, the by clause in the class declaration indicates that b will be stored internally in objects of Derived, and the compiler will generate all the methods of Base that forward to b. This means that the print() function in Derived will be automatically delegated to the print() function of the b object.

To see the delegation in action, let’s create an instance of BaseImpl with a value of 10 and pass it to the Derived class. Then, we can call the print() function on the Derived object:

fun main() {
    val b = BaseImpl(10)
    val derived = Derived(b)
    derived.print() // Output: 10
}

When we execute the print() function on the Derived object, it internally delegates the call to the BaseImpl object (b), and thus it prints the value 10.

Overriding Methods in Delegation

In Kotlin, when a class implements an interface by delegation, it can also override methods provided by the delegate object. This allows for customization and adding additional behavior specific to the implementing class.

Let’s extend our previous example to understand method overriding in the delegation. Assume we have an interface Base with two functions: printMessage() and printMessageLine():

interface Base {
    fun printMessage()
    fun printMessageLine()
}

We modify the BaseImpl class to implement the updated Base interface with the two functions printMessage() and printMessageLine():

class BaseImpl(val x: Int) : Base {
    override fun printMessage() {
        println(x)
    }
    override fun printMessageLine() {
        println("$xn")
    }
}

Now, let’s update the Derived class to override the printMessage() function:

class Derived(b: Base) : Base by b {
    override fun printMessage() {
        println("softAai")
    }
}

In this example, the printMessage() function in the Derived class overrides the implementation provided by the delegate object b. When we call printMessage() on an instance of Derived, it will print “softAai” instead of the original implementation.

To test the overridden behavior, we can modify the main() function as follows:

fun main() {
    val b = BaseImpl(10)
    val derived = Derived(b)
    derived.printMessage() // Output: softAai
    derived.printMessageLine() // Output: 10\n
}

When we call the printMessage() function on the Derived object, it invokes the overridden implementation in the Derived class, and it prints “softAai” instead of 10. However, the printMessageLine() function is not overridden in the Derived class, so it delegates the call to the BaseImpl object, which prints the original value 10 followed by a new line.

Property Delegation

In addition to method delegation, Kotlin also supports property delegation. This allows a class to delegate the implementation of properties to another object. Let’s understand how it works.

Assume we have an interface Base with a read-only property message:

interface Base {
    val message: String
}

We modify the BaseImpl class to implement the Base interface with the message property:

class BaseImpl(val x: Int) : Base {
    override val message: String = "BaseImpl: x = $x"
}

Now, let’s update the Derived class to delegate the Base interface and override the message property:

class Derived(b: Base) : Base by b {
    override val message: String = "Message of Derived"
}

In this example, the Derived class delegates the implementation of the Base interface to the b object. However, it overrides the message property and provides its own implementation.

To see the property delegation in action, we can modify the main() function as follows:

fun main() {
    val b = BaseImpl(10)
    val derived = Derived(b)
    println(derived.message) // Output: Message of Derived
}

When we access the message property of the Derived object, it returns the overridden value “Message of Derived” instead of the one in the delegate object b.

Delegated Properties in Kotlin

Delegated properties allow you to delegate the implementation of property accessors (getters and setters) to another object. This means that instead of writing the logic for accessing and setting the property directly in the class, you can delegate it to a separate class.

The general syntax for creating a delegated property is as follows:

class MyClass {
    var myProperty: Type by Delegate()
}

Here, myProperty delegates its getter and setter operations to the Delegate object.

Property Delegates

Property delegates are classes that implement the getValue and optionally setValue functions. These functions are invoked when the delegated property is accessed or modified.

The getValue function is responsible for returning the property value, and setValue is responsible for updating the property value.

Let’s say we have a Delegate class that will handle the logic for accessing and setting a property. The Delegate class should have two methods: getValue() and setValue(). The getValue() method retrieves the current value of the property, and the setValue() method sets a new value for the property. These methods can be defined as either members or extensions of the Delegate class.

Here’s an example of a Delegate class that simply stores the value internally:

class Delegate {
    private var value: Int = 0

    operator fun getValue(thisRef: Any?, property: KProperty<*>): Int {
        // Get the current value of the property
        return value
    }

    operator fun setValue(thisRef: Any?, property: KProperty<*>, newValue: Int) {
        // Set a new value for the property
        value = newValue
    }
}

In the above code snippet, the * is used in the parameter of the setValue() and getValue() methods of the Delegate class. This syntax is called a star-projection or star-spread operator.

In Kotlin, the KProperty interface represents a property, and it has a type parameter T that represents the type of property. When you use the star-projection (*) as the type argument (KProperty<*>), it means you are using a wildcard or an unknown type for the property.

In the context of delegated properties, the KProperty<*> parameter represents the property that is being accessed or set. The thisRef parameter represents the instance of the class that owns the property.

By using KProperty<*> with the star-projection, you’re saying that the property can be of any type. It allows you to create a generic Delegate class that can handle properties of different types without explicitly specifying the type.

Also, we defined the operator keyword, which is used to define and overload certain operators for custom types or classes.

Now, let’s create a class Foo with a property p that delegates its accessors to an instance of the Delegate class:

class Foo {
    var p: Int by Delegate()
    var q: String by Delegate()
}

fun main() {
    val foo = Foo()
    foo.p = 42
    foo.q = "softAai"

    println(foo.p) // Output: 42
    println(foo.q) // Output: softAai
}

When you create an instance of Foo, you can access and modify the p property as if it were a regular property. However, behind the scenes, the access and modification operations are delegated to the Delegate class.

Let’s consider one more example for better understanding, just create a simple UpperCaseDelegate that converts a string property to uppercase when accessed:

class UpperCaseDelegate {
    private var value: String = ""

    operator fun getValue(thisRef: Any?, property: KProperty<*>): String {
        return value.toUpperCase()
    }
}

To use this delegate:

class MyClass {
    var myProperty: String by UpperCaseDelegate()
}

fun main() {
    val obj = MyClass()
    obj.myProperty = "resume sender app"
    println(obj.myProperty) // Output: RESUME SENDER APP
}

Here, myProperty delegates its getter operation to UpperCaseDelegate, which converts the value to uppercase before returning it.

The “by" keyword

The delegate object is specified after the by keyword and can be any object that satisfies the rules of the convention for property delegates. It’s the delegate object that actually handles the logic for accessing and setting the property.

The by keyword is used in Kotlin to indicate that a property is delegated to another object or class. When you use the by keyword, you are specifying that the implementation of the property’s accessors (getters and setters) will be delegated to a separate delegate object.

By using the by keyword, you make it clear that the property’s implementation is delegated to another object, enhancing code readability and allowing for better separation of concerns.

class Delegate {
    private var value: Int = 0

    operator fun getValue(thisRef: Any?, property: KProperty<*>): Int {
        // Get the current value of the property
        return value
    }

    operator fun setValue(thisRef: Any?, property: KProperty<*>, newValue: Int) {
        // Set a new value for the property
        value = newValue
    }
}

class Foo {
    var p: Int by Delegate()
}

In the above example, the p property of the Foo class is delegated to an instance of the Delegate class using the by keyword. The Delegate class provides the implementation for the property’s accessors.

So, when you access or modify the p property of an instance of the Foo class, the property accessors are automatically delegated to the Delegate object. Behind the scenes, the getValue() and setValue() methods of the Delegate class are called to handle the property operations.

Using the by keyword simplifies the syntax and makes it clear that the property behavior is delegated to another object. It promotes code reuse and separates the concerns of the owning class from the delegate class.

Standard Delegates

Kotlin provides several standard delegates in the standard library to address common scenarios. Some examples include:

• lazy: Allows for lazy initialization of properties. The initialization is deferred until the property is accessed for the first time.
• observable: Enables observing property changes by providing a callback function that is triggered whenever the property value is modified.
• vetoable: Allows validation of property values by providing a callback function that can reject value changes based on specific conditions.

Lazy Initialization

Lazy initialization is a technique where you delay the initialization of an object until it is accessed for the first time. This can be useful when the initialization process is resource-intensive and the object might not always be needed during the lifetime of the program.

For example, consider a Person class that lets you access a list of the emails written by a person. The emails are stored in a database and take a long time to access. You want to load the emails on first access to the property and do so only once. Let’s say you have the following function loadEmails, which retrieves the emails from the database:

class Email {
    /*...*/
}

fun loadEmails(person: Person): List<Email> {
    println("Load emails for ${person.name}")
    return listOf(/*...*/ )
}

Here’s how you can implement lazy loading using an additional _emails property that stores null before anything is loaded and the list of emails afterward.

class Person(val name: String) {
    private var _emails: List<Email>? = null

    val emails: List<Email>
        get() {
            if (_emails == null) {
                _emails = loadEmails(this)
            }
            return _emails!!
        }
}

In this implementation, we have a nullable _emails property that acts as a backing property to store the loaded emails. The emails property is the one we access to retrieve the list of emails. In the getter of the emails property, we check if _emails is null. If it is, we initialize it by calling the loadEmails function. We then return the value of _emails, forcibly unwrapping it with !! operator since we know it won’t be null at this point.

While this approach works, it can become cumbersome and error-prone when dealing with multiple lazy properties. Additionally, the implementation is not thread-safe.

To simplify and improve the code, Kotlin provides a built-in solution using the lazy delegate. The lazy function returns an object that has a getValue method, which can be used together with the by keyword to create a delegated property. Here’s how we can use it in our example:

class Person(val name: String) {
    val emails by lazy { loadEmails(this) }
}

With this implementation, the emails property is delegated to the lazy delegate. The lambda expression passed to the lazy function is used to initialize the value of the property when it is accessed for the first time. The lazy delegate ensures that the initialization happens only once, and subsequent accesses to the property will return the cached value.

The lazy function is thread-safe by default, meaning that the initialization is synchronized and can be safely accessed from multiple threads. If you need more control over the thread-safety or want to optimize for a single-threaded environment, you can specify additional options to the lazy function.

Lazy delegate: “by lazy()”

In Kotlin, you can achieve lazy initialization using the lazy delegate provided by the standard library. The lazy function returns an object that has a getValue method, which can be used together with the by keyword to create a delegated property.

The lazy delegate is a built-in feature in Kotlin that allows you to create properties whose values are computed lazily. It provides a concise way to implement lazy initialization without manually managing the initialization state. Here’s how you can use it:

val property: Type by lazy {
    // Initialization code here
    // This block will be executed only once, when the property is accessed for the first time
    // The value of the block will be cached and returned for subsequent accesses
    // Return the computed value
}

Here’s an example to illustrate the usage of lazy initialization with the lazy delegate:

class Example {
    val expensiveProperty: Int by lazy {
        // Expensive computation or initialization
        println("Initializing expensiveProperty...")
        // Return the computed value
        42
    }
}

fun main() {
    val example = Example()
    println("Before accessing expensiveProperty")
    // The initialization code of expensiveProperty is not executed yet
    println("Value of expensiveProperty: ${example.expensiveProperty}")
    // The initialization code of expensiveProperty is executed here
    println("After accessing expensiveProperty")
    println("Value of expensiveProperty: ${example.expensiveProperty}")
    // The cached value is returned without re-initialization
}

OUTPUT

Before accessing expensiveProperty
Initializing expensiveProperty...
Value of expensiveProperty: 42
After accessing expensiveProperty
Value of expensiveProperty: 42

In this example, the expensiveProperty in the Example class is lazily initialized using the lazy delegate. The initialization code block is not executed until the property is accessed for the first time. The computed value (42 in this case) is then cached and returned for subsequent accesses.

When you run the above code, you’ll see that the initialization code block is executed only once, when the property is first accessed. On subsequent accesses, the cached value is returned without re-executing the initialization code.

Lazy initialization with by lazy() simplifies the code by abstracting away the details of managing the initialization state and caching the computed value. It ensures that the property is initialized lazily and provides a convenient way to implement lazy initialization in Kotlin.

Once again here’s an example to illustrate lazy initialization using the lazy delegate:

class Person(val name: String) {
    val emails by lazy { loadEmails(this) }
}

In this example, the Person class has a property called emails, which is lazily initialized using the lazy delegate. The lazy function takes a lambda as an argument, which it will call to initialize the value of the property when it is accessed for the first time.

The benefit of using the lazy delegate is that the initialization logic is encapsulated within it. The value assigned to the emails property will only be computed once, on the first access, and subsequent accesses will return the cached value. This can help improve performance by avoiding unnecessary computations or resource allocations until they are actually needed.

You can think of the emails property as having a backing property that holds the computed value, and the lazy delegate takes care of initializing and caching the value behind the scenes. The delegate ensures that the value is computed lazily, i.e., only when it is first accessed.

Here’s how you would use the Person class:

val person = Person("amol")
println(person.emails) // Initialization happens here, loadEmails() is called
println(person.emails) // Cached value is returned without re-initialization

In this example, the loadEmails() function will only be called on the first access of the emails property. Subsequent accesses will return the cached value without re-initializing it.

The lazy delegate is thread-safe by default, meaning that the initialization is synchronized and can be safely accessed from multiple threads. However, if you know that the class will only be used in a single-threaded environment, you can provide additional options to bypass synchronization and improve performance.

The lazy delegate allows you to achieve lazy initialization of properties. It simplifies the code by encapsulating the initialization logic and ensures that the value is computed only when it is first accessed, providing better performance and resource utilization.

"observable” Delegate

The observable delegate allows you to observe property changes by providing a callback function that is triggered whenever the property value is modified.

Here’s the general syntax for using the observable delegate:

var propertyName: Type by Delegates.observable(initialValue) { property, oldValue, newValue ->
    // Callback function logic
}

Let’s see an example that uses the observable delegate to observe changes in a property:

import kotlin.properties.Delegates

class Person {
    var age: Int by Delegates.observable(25) { property, oldValue, newValue ->
        println("Age changed from $oldValue to $newValue")
    }
}

fun main() {
    val person = Person()
    person.age = 30 // Output: Age changed from 25 to 30
    person.age = 35 // Output: Age changed from 30 to 35
}

In this example, the age property is observed using the observable delegate. Whenever the age property is modified, the callback function is triggered, printing the old value and the new value.

"vetoable” Delegate

The vetoable delegate allows you to validate property values by providing a callback function that can reject value changes based on specific conditions.

Here’s the general syntax for using the vetoable delegate:

var propertyName: Type by Delegates.vetoable(initialValue) { property, oldValue, newValue ->
    // Validation logic
    // Return true to accept the new value, or false to reject it
}

Let’s see an example that uses the vetoable delegate to validate a property value:

import kotlin.properties.Delegates

class Circle {
    var radius: Double by Delegates.vetoable(0.0) { property, oldValue, newValue ->
        newValue >= 0.0 // Only accept positive or zero radius values
    }
}

fun main() {
    val circle = Circle()
    circle.radius = 5.0
    println(circle.radius) // Output: 5.0

    circle.radius = -2.0 // Value rejected due to validation
    println(circle.radius) // Output: 5.0 (unchanged)
}

In this example, the radius property is validated using the vetoable delegate. The callback function checks if the new value is greater than or equal to zero. If the validation condition is not met (e.g., negative radius), the value change is rejected, and the property retains its previous value.

Delegating to another property

Delegating a property to another property means that the getter and setter of one property are implemented by accessing or modifying another property’s value. This delegation can be done for top-level properties, member properties (including extension properties) within the same class, or even member properties of another class.

To delegate a property to another property, you use the :: qualifier followed by the delegate property’s name. Here are a few examples to illustrate how property delegation works:

var topLevelInt: Int = 0

class ClassWithDelegate(val anotherClassInt: Int)

class MyClass(var memberInt: Int, val anotherClassInstance: ClassWithDelegate) {
    var delegatedToMember: Int by this::memberInt
    var delegatedToTopLevel: Int by ::topLevelInt

    val delegatedToAnotherClass: Int by anotherClassInstance::anotherClassInt
}

var MyClass.extDelegated: Int by ::topLevelInt

In the code above, we have different scenarios for property delegation:

1. delegatedToMember is a property within the MyClass class that delegates its getter and setter to the memberInt property of the same class. This means that accessing or modifying delegatedToMember will actually read from or write to memberInt.
2. delegatedToTopLevel is a property within the MyClass class that delegates its getter and setter to the top-level property topLevelInt. So, accessing or modifying delegatedToTopLevel will actually read from or write to topLevelInt.
3. delegatedToAnotherClass is a property within the MyClass class that delegates its getter to the anotherClassInt property of an instance of ClassWithDelegate. This means that accessing delegatedToAnotherClass will read the value of anotherClassInstance.anotherClassInt.
4. extDelegated is an extension property of MyClass that delegates its getter and setter to the top-level property topLevelInt. This allows instances of MyClass to have an additional property extDelegated that shares its value with topLevelInt.

Property delegation can be useful in various scenarios. One common use case is when you want to introduce a new property while maintaining backward compatibility with an existing one. In such cases, you can introduce a new property, annotate the old property with the @Deprecated annotation, and delegate its implementation to the new property. Here’s an example:

class MyClass {
    var newName: Int = 0

    @Deprecated("Use 'newName' instead", ReplaceWith("newName"))
    var oldName: Int by this::newName
}

fun main() {
    val myClass = MyClass()
    // Notification: 'oldName: Int' is deprecated.
    // Use 'newName' instead
    myClass.oldName = 42
    println(myClass.newName) // Output: 42
}

In this example, we have a class MyClass with oldName and newName properties. The oldName property is deprecated and annotated with @Deprecated, indicating that it should not be used anymore. The implementation of oldName is delegated to the newName property using by this::newName. So, accessing or modifying oldName will actually access or modify the newName property.

In the main function, we demonstrate the usage of the deprecated oldName property. When assigning a value to oldName, a deprecation warning is displayed. However, the value is stored in the newName property, which can be accessed correctly.

Overall, delegating properties to other properties provides a powerful mechanism to reuse existing property implementations, introduce backward compatibility, and simplify property access and modification.

Property delegate requirements

Property delegate requirements will be demonstrated for both read-only (val) and mutable (var) properties. Let’s break down the concept of delegated properties for read-only and mutable properties (var) and understand how to provide the necessary operator functions for delegation.

For a read-only property (val), the delegate must provide the getValue() operator function with the following parameters:

• thisRef: This parameter should be the same type as, or a supertype of, the property owner (for extension properties, it should be the type being extended).
• property: This parameter should be of type KProperty<*> or its supertype.
• getValue(): This function must return the same type as the property (or its subtype).

Here’s an example:

class Resource

class Owner {
    val valResource: Resource by ResourceDelegate()
}

class ResourceDelegate {
    operator fun getValue(thisRef: Owner, property: KProperty<*>): Resource {
        return Resource()
    }
}

In this code, we have the Owner class with a read-only property valResource. The delegation is done by using the by keyword and providing an instance of the ResourceDelegate class. The ResourceDelegate class defines the getValue() function, which returns an instance of Resource. The function receives the property owner (thisRef) and the KProperty<*> instance representing the property being delegated.

For a mutable property (var), in addition to the getValue() function, the delegate must provide the setValue() operator function with the following parameters:

• thisRef: This parameter should be the same type as, or a supertype of, the property owner (for extension properties, it should be the type being extended).
• property: This parameter should be of type KProperty<*> or its supertype.
• value: This parameter should be of the same type as the property (or its supertype).

Here’s an example:

class Resource

class Owner {
    var varResource: Resource by ResourceDelegate()
}

class ResourceDelegate(private var resource: Resource = Resource()) {
    operator fun getValue(thisRef: Owner, property: KProperty<*>): Resource {
        return resource
    }

    operator fun setValue(thisRef: Owner, property: KProperty<*>, value: Any?) {
        if (value is Resource) {
            resource = value
        }
    }
}

In this code, we have the Owner class with a mutable property varResource. The ResourceDelegate class now includes the setValue() function, which allows modifying the value of the delegated property. The function receives the property owner (thisRef), the KProperty<*> instance representing the property being delegated, and the new value to be assigned.

You can define the getValue() and setValue() functions as member functions of the delegate class itself or as extension functions. Both functions need to be marked with the operator keyword to enable operator overloading.

Alternatively, you can create delegates as anonymous objects using the interfaces ReadOnlyProperty and ReadWriteProperty from the Kotlin standard library. These interfaces provide the required getValue() and setValue() methods. By using anonymous objects, you can avoid creating separate classes for the delegates. Here’s an example:

fun resourceDelegate(resource: Resource = Resource()): ReadWriteProperty<Any?, Resource> =
    object : ReadWriteProperty<Any?, Resource> {
        private var curValue = resource

        override fun getValue(thisRef: Any?, property: KProperty<*>): Resource = curValue

        override fun setValue(thisRef: Any?, property: KProperty<*>, value: Resource) {
            curValue = value
        }
    }

val readOnlyResource: Resource by resourceDelegate()  // ReadWriteProperty used as a read-only property
var readWriteResource: Resource by resourceDelegate()  // ReadWriteProperty used as a mutable property

In this code, the resourceDelegate() function returns an anonymous object implementing the ReadWriteProperty interface. The ReadWriteProperty interface extends ReadOnlyProperty, so it can be used as a delegate for both read-only and mutable properties. The anonymous object defines the necessary getValue() and setValue() functions.

By using delegated properties and providing the appropriate operator functions, you can create flexible and reusable property delegation patterns in Kotlin.

Storing property values in a map

Another common pattern where delegated properties come into play is objects that have a dynamically defined set of attributes associated with them. Such objects are sometimes called expando objects. in a contact-management system, each person may have some required properties (like name) that are handled in a special way, as well as additional attributes that can vary for each person(youngest child’s birthday, for example).

One way to implement such a system is by using a map to store all the attributes of a person and providing properties that allow access to the information with special handling. Let’s go through the code examples to understand this approach.

First, we have the Person class with a private _attributes map. This map will store the attributes of a person, where the keys are attribute names and the values are attribute values.

class Person {
    private val _attributes = hashMapOf<String, String>()

    fun setAttribute(attrName: String, value: String) {
        _attributes[attrName] = value
    }

    val name: String
        get() = _attributes["name"]!!
}

In this code, we have a set attributefunction that allows adding or updating attributes in the _attributes map. The name property is an example of a required property that is handled in a special way. It retrieves the value of the “name” attribute from the _attributes map.

To create an instance of the Person class and load data into it, we can use a generic API, such as deserialization from JSON, as shown in the example below:

val p = Person()
val data = mapOf("name" to "amol", "company" to "softAai")

for ((attrName, value) in data) {
    p.setAttribute(attrName, value)
}

println(p.name) // Output: amol

Here, we create a new Person instance and provide the data as a map. We iterate over each key-value pair in the data map and call setAttribute to store the attributes in the _attributes map. Finally, we can access the name property, which internally retrieves the value of the “name” attribute from the _attributes map.

Now, instead of manually implementing the property and the _attributes map, we can simplify the code using delegated properties. We can directly delegate the name property to the _attributes map using the by keyword, as shown below:

class Person {
    private val _attributes = hashMapOf<String, String>()

    fun setAttribute(attrName: String, value: String) {
        _attributes[attrName] = value
    

    val name: String by _attributes
}

In this code, we no longer have the explicit getter for the name property. Instead, we use the by keyword to delegate the property to the _attributes map. The standard library provides getValue and setValue extension functions for maps, allowing the property to automatically get and set the values in the map based on the property name.

With the delegated property in place, we can use it just like before:

val p = Person()
val data = mapOf("name" to "amol", "company" to "softAai")

for ((attrName, value) in data) {
    p.setAttribute(attrName, value)
}

println(p.name) // Output: amol

The output remains the same, but now the name property is implemented as a delegated property, simplifying the code and removing the need for an explicit getter.

Delegated properties provide a concise and reusable way to handle dynamically defined attributes in expando objects. By leveraging the by keyword and the standard library extension functions, we can delegate the property access to a map or any other custom logic, making the code more maintainable and flexible.

Translation rules for delegated properties

When using delegated properties in Kotlin, the Kotlin compiler generates auxiliary properties to handle the delegation. These auxiliary properties are used to store the delegate object and manage the getter and setter operations.

Let’s take an example to understand how this works. Consider the following code:

class C {
    var prop: Type by MyDelegate()
}

When the compiler encounters this code, it generates a hidden property called prop$delegate. This hidden property is of the same type as the delegate class (MyDelegate in this case). It is responsible for handling the delegation of the prop property.

The generated code looks like this:

class C {
    private val prop$delegate = MyDelegate()
    var prop: Type
        get() = prop$delegate.getValue(this, this::prop)
        set(value: Type) = prop$delegate.setValue(this, this::prop, value)
}

In the generated code, the prop property has a getter and a setter. The getter delegates the getValue() operation to the prop$delegate property, passing the instance of the outer class (this) and the reflection object (this::prop) that represents the property itself. The delegate’s getValue() function is responsible for providing the value of the property.

Similarly, the setter delegates the setValue() operation to the prop$delegate property, passing the instance of the outer class (this), the reflection object (this::prop), and the new value of the property. The delegate’s setValue() function handles the assignment of the new value.

By generating the prop$delegate property and delegating to it, the compiler ensures that the getter and setter operations are correctly handled by the delegate object (MyDelegate).

Optimized cases for delegated properties

When it comes to optimization, the Kotlin compiler can omit the $delegate field in certain cases. Here are the optimized cases for delegated properties:

A referenced property:

class C<Type> {
    private var impl: Type = ...
    var prop: Type by ::impl
}

In this case, the property prop is delegated to another property impl using the by keyword. Since the delegate is a referenced property within the same class, the compiler can optimize the generated code and omit the $delegate field. Instead, the accessors directly delegate to the referenced property impl.

A named object:

object NamedObject {
    operator fun getValue(thisRef: Any?, property: KProperty<*>): String = ...
}

val s: String by NamedObject

When using a named object as a delegate, the Kotlin compiler can optimize the code and omit the $delegate field. The accessors directly call the delegate’s getValue function without the need for an intermediate property.

A final val property with a backing field and a default getter in the same module:

val impl: ReadOnlyProperty<Any?, String> = ...

class A {
    val s: String by impl
}

In this case, the delegate impl is a final val property with a backing field and a default getter defined in the same module as the property s. The compiler can optimize the code and omit the $delegate field. The accessors directly delegate to the getValue function of the delegate without the need for an intermediate property.

A constant expression, enum entry, this, or null:

class A {
    operator fun getValue(thisRef: Any?, property: KProperty<*>) ...

    val s by this
}

If the delegate is a constant expression, an enum entry, this, or null, the Kotlin compiler can optimize the code and omit the $delegate field. The accessors directly call the getValue function of the delegate without the need for an intermediate property.

In these optimized cases, the compiler eliminates the need for the $delegate field, which can save memory and provide more efficient property access. The accessors directly invoke the corresponding functions of the delegate, leading to more streamlined code execution.

Note that these optimizations are applied by the Kotlin compiler to improve performance and reduce unnecessary overhead when using delegated properties.

Translation rules when delegating to another property

When delegating to another property, the Kotlin compiler optimizes the code by generating immediate access to the referenced property. This means that the compiler doesn’t generate the $delegate field. This optimization helps save memory and improves performance.

Let’s take a look at the example code:

class C<Type> {
    private var impl: Type = ...
    var prop: Type by ::impl
}

In this case, the property prop is delegated to the property impl using the by keyword. The compiler optimizes the code by directly accessing the impl property within the property accessors of prop. This means that the delegated property’s getValue and setValue operators are skipped, and there is no need for the KProperty reference object.

The compiler generates the following code:

class C<Type> {
    private var impl: Type = ...

    var prop: Type
        get() = impl
        set(value) {
            impl = value
        }

    fun getProp$delegate(): Type = impl // This method is needed only for reflection

As you can see, the accessors for the prop property directly delegate to the impl property. The getValue accessor returns the value of impl, and the setValue accessor assigns the value to impl.

The method getProp$delegate() is also generated, but it is only needed for reflection purposes. It allows reflective access to the delegate object, but it is not used in regular property access.

This optimization avoids the creation of an additional field and reduces the overhead associated with delegated property access. By directly accessing the referenced property, the code becomes more efficient and memory-friendly.

The same optimization principle applies when delegating to another property using this keyword. The compiler generates immediate access to the referenced property without the need for an intermediate field.

Overall, these translation rules improve the performance of delegated properties and eliminate unnecessary memory usage.

What will be the right-hand side of “by"?

In Kotlin, when using delegated properties, the expression to the right of the by keyword can be more than just a new instance creation. It can also be a function call, another property, or any other expression, as long as the value of the expression is an object that provides the getValue and setValue methods with the correct parameter types.

The getValue and setValue methods can be declared directly on the object itself or defined as extension functions. This gives you the flexibility to use existing functions or properties to handle the behavior of your delegated properties.

Here’s an example to demonstrate this concept:

class Example {
    var value: String = "initial"

    // Delegated property using a function call
    var customValue: String by getValueFromFunction()

    // Delegated property using another property
    var anotherValue: String by ::value

    // Delegated property using an extension function
    var computedValue: Int by calculateValue()

    // Extension function providing delegated property behavior
    private fun calculateValue(): ReadWriteProperty<Any?, Int> {
        var storedValue: Int = 0

        return object : ReadWriteProperty<Any?, Int> {
            override fun getValue(thisRef: Any?, property: KProperty<*>): Int {
                // Perform custom logic to compute the value
                return storedValue * 2
            }

            override fun setValue(thisRef: Any?, property: KProperty<*>, value: Int) {
                // Perform custom logic to store the value
                storedValue = value / 2
            }
        }
    }
}

fun getValueFromFunction(): ReadWriteProperty<Any?, String> {
    var storedValue: String = ""

    return object : ReadWriteProperty<Any?, String> {
        override fun getValue(thisRef: Any?, property: KProperty<*>): String {
            return storedValue
        }

        override fun setValue(thisRef: Any?, property: KProperty<*>, value: String) {
            storedValue = value.toUpperCase()
        }
    }
}

fun main() {
    val example = Example()

    // Using the delegated properties
    example.customValue = "amol"
    println(example.customValue) // Output: AMOL

    example.anotherValue = "softAai"
    println(example.anotherValue) // Output: softAai

    example.computedValue = 5
    println(example.computedValue) // Output: 10
}

In the example above, the customValue property is delegated to the result of a function call getValueFromFunction(), which returns a custom delegate object implementing the ReadWriteProperty interface. The delegate modifies the stored value by converting it to uppercase when setting the value.

The anotherValue property is delegated to the value property using the ::value syntax. Any changes made to anotherValue will be reflected in the value property.

The computedValue property is delegated to the result of the calculateValue() extension function. The extension function provides the delegated property behavior by implementing the ReadWriteProperty interface. In this case, the delegate computes the value by multiplying it by 2 and stores the value by dividing it by 2.

By allowing various expressions on the right-hand side of by and supporting both object-defined and extension-defined getValue and setValue methods, Kotlin enables flexible and customizable behavior for delegated properties.

Providing a delegate

The provideDelegate operator allows you to extend the logic for creating the object to which the property implementation is delegated. If the object used on the right-hand side of the by keyword defines provideDelegate as a member or extension function, that function will be called to create the property delegate instance.

One use case of provideDelegate is to perform additional checks or actions during the initialization of the property delegate. For example, you can check the consistency of the property before binding it.

Here’s an example that demonstrates how to use provideDelegate:

class ResourceDelegate<T> : ReadOnlyProperty<MyUI, T> {
    override fun getValue(thisRef: MyUI, property: KProperty<*>): T { ... }
}

class ResourceLoader<T>(id: ResourceID<T>) {
    operator fun provideDelegate(
            thisRef: MyUI,
            prop: KProperty<*>
    ): ReadOnlyProperty<MyUI, T> {
        checkProperty(thisRef, prop.name)
        // create delegate
        return ResourceDelegate()
    }

    private fun checkProperty(thisRef: MyUI, name: String) { ... }
}

class MyUI {
    fun <T> bindResource(id: ResourceID<T>): ResourceLoader<T> { ... }

    val image by bindResource(ResourceID.image_id)
    val text by bindResource(ResourceID.text_id)
}

In this example, the ResourceLoader class defines the provideDelegate function. This function is called for each property during the creation of an instance of MyUI. It performs the necessary validation or checks before creating the property delegate.

Without the provideDelegate functionality, you would need to pass the property name explicitly to achieve the same functionality, which could be less convenient.

The provideDelegate method has the same parameters as the getValue function:

• thisRef must be the same type as, or a supertype of, the property owner (for extension properties, it should be the type being extended).
• property must be of type KProperty<*> or its supertype.

The provideDelegate method is responsible for creating and returning the property delegate instance that will handle the property access.

In the generated code, when provideDelegate is present, it is called to initialize the auxiliary prop$delegate property. Compare the generated code for the property declaration val prop: Type by MyDelegate() with the generated code when provideDelegate is available:

class C {
    var prop: Type by MyDelegate()
}

// Generated code with `provideDelegate` function:
class C {
    // Calling `provideDelegate` to create the additional `delegate` property
    private val prop$delegate = MyDelegate().provideDelegate(this, this::prop)
    var prop: Type
        get() = prop$delegate.getValue(this, this::prop)
        set(value: Type) = prop$delegate.setValue(this, this::prop, value)
}

It’s important to note that the provideDelegate method only affects the creation of the auxiliary property (prop$delegate) and does not impact the generated code for the getter or the setter of the delegated property.

You can also use the PropertyDelegateProvider interface from the standard library to create delegate providers without creating new classes. Here’s an example:

val provider = PropertyDelegateProvider { thisRef: Any?, property ->
    ReadOnlyProperty<Any?, Int> { _, property -> 42 }
}
val delegate: Int by provider

In this case, the PropertyDelegateProvider creates a delegate provider using a lambda expression. The lambda receives the thisRef (property owner) and property information and returns a property delegate instance.

Delegation in Android Applications

Kotlin delegation and delegated properties can be useful in Android applications to simplify code, separation of concerns, and provide flexibility in handling certain tasks. Here are a few examples of how delegation can be used in Android applications:

1. Shared Preferences Delegation

Android applications often need to store and retrieve key-value pairs using SharedPreferences. Delegation can be used to simplify the code for accessing SharedPreferences. For example:

class SettingsManager(context: Context) {
    private val preferences: SharedPreferences by lazy {
        context.getSharedPreferences("settings", Context.MODE_PRIVATE)
    }

    var isNotificationsEnabled: Boolean by BooleanPreferenceDelegate(
        preferences, "notifications_enabled", true
    )
}

class BooleanPreferenceDelegate(
    private val preferences: SharedPreferences,
    private val key: String,
    private val defaultValue: Boolean
) {
    operator fun getValue(thisRef: Any?, property: KProperty<*>): Boolean {
        return preferences.getBoolean(key, defaultValue)
    }

    operator fun setValue(thisRef: Any?, property: KProperty<*>, value: Boolean) {
        preferences.edit { putBoolean(key, value) }
    }
}

In this example, the SettingsManager class uses delegation to handle the isNotificationsEnabled property, which is backed by a shared preference value. The BooleanPreferenceDelegate class implements the delegated property behavior.

2. Dependency Injection with Delegation:

Dependency injection frameworks like Dagger can benefit from delegation to simplify the injection process. By using a delegated property, you can abstract away the complexity of dependency resolution. Here’s a simplified example:

class MyActivity : AppCompatActivity() {
    private val myDependency: MyDependency by inject()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // Use myDependency
    }
}

interface Injectable {
    fun injectDependencies()
}

class MyDependency {
    // Dependency implementation
}

inline fun <reified T : Injectable> AppCompatActivity.inject(): Lazy<T> {
    return lazy {
        val injectable = T::class.java.newInstance()
        injectable.injectDependencies()
        injectable
    }
}