I have this problem a lot. I need a class that runs some util function. My past experience basicall...

# getting-started

[Colton Idle]

I have this problem a lot.

I need a class that runs some util function. My past experience basically says that objects/singletons are bad, so I should define something like

class SomeUtil {
    fun findPercentage(x: Int, y: Int, z: Int)

but something like this

object SomeUtil {
    fun findPercentage(x: Int, y: Int, z: Int)

is also convenient + less object allocation because I dont have to do SomeUtil() every time I want to use it.

I suppose another potential is creating an extension function, but in this case since I have three args... I don't think that'd work?

In this scenario would you do
1️⃣ Class
2️⃣ Object
3️⃣ Something else

[Javier]

As there isn’t a clear receiver for an extension function, I would create a top level function without any class or object

[PoisonedYouth]

Top-level function is no option because of pollution of the namespace?

[Francesc]

without more context, it depends.
I would consider creating a class like

data class MyClass(
   val x: Int, /* consider better name */
   val y: Int,
   val z: Int,
)

then either create the percentage as a property in the class if it's intrinsic to this object, or define an extension property on MyClass otherwise

val MyClass.percentage: Int
    get() = /* compute */

[Youssef Shoaib [MOD]]

Objects aren't bad, at least the way they're used in Kotlin aren't. Global mutable state is bad.

[ephemient]

objects just for namespacing involves a bit more than ideally necessary. https://youtrack.jetbrains.com/issue/KT-11968 may improve that, but in general I'd just go with top-level functions (possibly in their own package)

[Colton Idle]

Ooh. forgot about just a top level function (but adding more top level functions seems... eh.) but a new data class with a percentage property seems cool!

[Matteo Mirk]

I don't know why so many people are worried about public top level functions polluting the namespace? They are confined to their package and must be imported explicitly: this isn't Javascript! 😆

[Colton Idle]

interesting. maybe im worrying about it too much.

[Matteo Mirk]

Maybe JS burned too many a devs

[PoisonedYouth]

Even though I'm a non JS developer I'm worried 😂

[Francesc]

even if they are confined to their package, they show in autocompletion. I prefer to minimize what's exposed publicly.

[PoisonedYouth]

Yes the autocompletion is the main problem

[ephemient]

regardless of whether it's top-level vs in an object, IntelliJ is totally happy to auto-import it, which I use way more than name autocomplete. so I don't find there to be much of a difference

[Francesc]

hence my preference for creating a type and then an extension function on the type (or a member function if relevant), as opposed to plain top level functions

[ephemient]

if there's a sensible receiver, sure. but IMO naturalOrder() , etc. make more sense as a top-level function than belonging to Comparator (to give an example from stdlib) and I think that can make sense for some of your own types too

[Francesc]

yes, for generic utilities that would apply across the board, that makes sense