Question

0

462

Visualizações

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?

over 4 years ago · Santiago Trujillo

3 Respostas

Responde à pergunta

0

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())
}

over 4 years ago · Santiago Trujillo Relatório

0

Personal preference.

My view would be, if you don't need to pass it anything, then create it as a property.

But if you need to pass it more information, it will have to be a function!

over 4 years ago · Santiago Trujillo Relatório

Responde à pergunta

Encontrar trabalhos remotos

Accepted Answer · 2022-05-24T16:06:26.103Z

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.

0

462