> Use property if… is cheap to calculate When d...

# announcements

[nil2l]

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

val File.entropy: Float
    get() = TODO()

#2

fun File.getEntropy(): Float = TODO()

[streetsofboston]

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.

[nil2l]

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.

[Sam Garfinkel]

@streetsofboston Regarding your second point, any reason you wouldn’t just use by lazy {}

[streetsofboston]

You can use that too if repeated construction of the objects is expensive

[streetsofboston]

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.

[streetsofboston]

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.)

[nil2l]

Ok, I’v added examples. Please choose one 🙂

[streetsofboston]

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.

[streetsofboston]

You can still use getEntropy(), that is fine, but it wouldn’t be my first choice 🙂

[nil2l]

Oh man ….

[streetsofboston]

It’s mostly about style 🙂
Do you want i = i + 1 or i++ ? Both are perfectly fine 🙂

[nil2l]

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.

[streetsofboston]

But in an extension-function, you can’t store/cache it…., whether you use a extension function or extension property…

[nil2l]

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”.

[Matteo Mirk]

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.

[nil2l]

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

[nil2l]

But for C# it’s well known moment.

[Matteo Mirk]

Yeah, I agree with the .NET guideline!