https://kotlinlang.org logo
#announcements
Title
# announcements
n

nil2l

06/03/2020, 6:12 PM
Use property if… is cheap to calculate
When deciding to use property or function/method. Do you think this guideline about the calculation heaviness is significant? E.g. #1
Copy code
val File.entropy: Float
    get() = TODO()
#2
Copy code
fun File.getEntropy(): Float = TODO()
2️⃣ 2
1️⃣ 1
s

streetsofboston

06/03/2020, 6:18 PM
It depends on taste, but this is what I go by: If it would return different objects (if you would call
equals
among the returned objects, and any of those
equals
calls may return
false
) always use a function/method. If it would always return the same object, use a property. If something needs to be lazily evaluated, still use a property, but implement its
get()
getter.
n

nil2l

06/03/2020, 6:50 PM
Well, the question is about only this guideline. I know there are other. lazy/caching — doesn’t suit for extension func/props. Maybe I need edit the question a bit.
s

Sam Garfinkel

06/03/2020, 8:01 PM
@streetsofboston Regarding your second point, any reason you wouldn’t just use
by lazy {}
s

streetsofboston

06/03/2020, 8:02 PM
You can use that too if repeated construction of the objects is expensive
For (abstract) classes, i indeed tend to use
by lazy
quite a lot. For top level functions/properties, this is not possible and I use a
get() =
instead.
Also, use class/interface properties if it has a has-a relation-ship with the class/interface (
List.size
). If it doesn’t, and it is more of a translations/mutations, I use function/method (e.g.
toInt()
or
toList()
or
asXXXX()
, etc.)
n

nil2l

06/03/2020, 8:10 PM
Ok, I’v added examples. Please choose one 🙂
s

streetsofboston

06/03/2020, 8:17 PM
A file is-not-an entropy, nor an entropy is-a file; it has-a entropy. And if the returned entropy value never changes, I would use a property, not a function.
1
You can still use
getEntropy()
, that is fine, but it wouldn’t be my first choice 🙂
n

nil2l

06/03/2020, 8:33 PM
Oh man ….
s

streetsofboston

06/03/2020, 8:39 PM
It’s mostly about style 🙂 Do you want
i = i + 1
or
i++
? Both are perfectly fine 🙂
n

nil2l

06/03/2020, 8:39 PM
Yes, it’s a property of a file. Sure, the returned entropy value may be changed. Because the file may. It’s not pure function. Sure. Both options may be used. But there is a point — prop-option (calculated every time, ok) looks not good here, because the cost of the call is pretty expensive.
s

streetsofboston

06/03/2020, 8:39 PM
But in an extension-function, you can’t store/cache it…., whether you use a extension function or extension property…
n

nil2l

06/03/2020, 8:59 PM
Right. But there is a different perception for the one who uses it. If you follow this guideline, a property looks like “quick and cheap.” And a function as “complex calculations”.
m

Matteo Mirk

06/04/2020, 12:52 PM
I think that such a guideline is very opinionated. Kotlin, like C#, introduced properties to hide accessor methods in a transparent way, so the only convention that matters to me is “this is a property” (I don’t care if computed, expensive or not) opposed to “this is a function”, I don’t care if expensive or not: those details should be explained in the API documentation.
n

nil2l

06/04/2020, 12:59 PM
Thanks for C# mention. 🙂 I couldn’t find design guideline for the subject for Kotlin.
In general, methods represent actions and properties represent data. Properties are meant to be used like fields, meaning that properties should not be computationally complex or produce side effects. When it does not violate the following guidelines, consider using a property, rather than a method, because less experienced developers find properties easier to use.
https://docs.microsoft.com/en-us/previous-versions/dotnet/netframework-4.0/ms229054(v=vs.100)?redirectedfrom=MSDN
👍 1
But for C# it’s well known moment.
m

Matteo Mirk

06/04/2020, 1:06 PM
Yeah, I agree with the .NET guideline!