Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Kotlin: fun vs val

Kotlin supports computed properties but I am not sure when to use them.

Let's say I have a class:

class Car(val color: String)

and have this function that returns true if the car is white:

fun isWhite(car: Car): Boolean {
  return car.color == "WHITE"
}

Now I want this function to be a member function (a method); this would look like this:

class Car(val color: String) {
  fun isWhite(): Boolean = color == "WHITE"
}

but it can also look like this:

class Car(val color: String) {
  val isWhite: Boolean get() = color == "WHITE"
}

So, which one is better?

like image 331
functionaldude Avatar asked Mar 01 '19 17:03

functionaldude


People also ask

What does fun mean in Kotlin?

In Kotlin functions are declared with the fun keyword and they are first-class citizen. It means that functions can be assigned to the variables, passed as an arguments or returned from another function.

Can Val be changed in Kotlin?

VAL(Value) The object stored using val cannot be changed, it cannot be reassigned, it is just like the final keyword in java. val is immutable.

Is there final in Kotlin?

Kotlin function parameters are final. There is no val or final keyword because that's the default (and can't be changed).

How do you make fun with Kotlin?

Creating user-defined function-fun– Keyword to define a function. fun_name – Name of the function which later used to call the function. a: data_type – Here, a is an argument passed and data_type specify the data type of argument like integer or string.


Video Answer


2 Answers

The official Kotlin Coding Conventions defines in section Functions vs Properties the following:

In some cases functions with no arguments might be interchangeable with read-only properties. Although the semantics are similar, there are some stylistic conventions on when to prefer one to another.

Prefer a property over a function when the underlying algorithm:

  • does not throw
  • is cheap to calculate (or caсhed on the first run)
  • returns the same result over invocations if the object state hasn't changed

So, I would use in the above example a val for isWhite, since it does not throw, the string comparison is cheap to calculate and the color of the Car can't change, as the Car.color is itself defined as val.

Compiled difference

Note that the JVM bytecode of the get() block will get compiled to the exact same code as the function would have. So, both approaches are the same regarding the compiled bytecode and there is no performance difference.

like image 125
vonox7 Avatar answered Sep 29 '22 22:09

vonox7


To add to other answers, these are from the book Java to Kotlin, chapter 11 Methods to Properties:

Example 1

Suppose we want to add age to this class:

data class Person(val dateOfBirth: LocalDate)

We can compute age easily (ignoring time zones) from the dateOfBirth property. But this doesn’t depend only on that property; it also depends on when we call it.
Unlikely though it is, fred.age == fred.age can return false.

Age is an action; its result depends on when it is called. Properties should be calculations, timeless and dependent only on their inputs, in this case the dateOfBirth property.
Hence, age() should be a function, not a property:

data class Person(val dateOfBirth: LocalDate) {
    fun age() = Period.between(dateOfBirth, LocalDate.now()).years
}

Example 2

What if we want a cryptographic hash of all the other properties of the object? This is a calculation (for immutable objects), but if it is expensive to compute, it should be a method hash() not a property hash. We might even want to hint at the cost of the method in its name:

data class PersonWithProperties(
    val givenName: String,
    val familyName: String,
    val dateOfBirth: LocalDate
) {
    fun computeHash(): ByteArray =
        someSlowHashOf(givenName, familyName, dateOfBirth.toString())
}
like image 36
Mahozad Avatar answered Sep 29 '22 23:09

Mahozad