what is the best way to force the initialization o...

# getting-started

[david-wg2]

what is the best way to force the initialization of the fields on an object, ex

object Config {
    val port = System.getenv("PORT") ?: 8080
}

[david-wg2]

i want to init this on startup

[Big Chungus]

They're initialised together with the object. However kotlin's objects are lazy

[Big Chungus]

Meaning they're only initialised upon the first request

[Big Chungus]

So to force that on startup just call it in main
```
fun main() {
Config
}

[david-wg2]

is this considered the proper way of doing it ?

[david-wg2]

it’s what i’m currently doing, but it looks so wrong

[Big Chungus]

Well not quite. It's the equvivalent of Config(), just makes it globally accessible afterwards

[Big Chungus]

You could implement an object manager class/function, which would force the declared object initialisation:

class ObjectManager {
  init {
    Object1
    Config
    AnotherObject
  }
}

fun main() {
  ObjectManager()
}

[diesieben07]

If you need something initialized at a specific time, then lazy singleton (which Kotlin's object is) is not the right pattern for you

[david-wg2]

hmm.. the alternative seems to be to make it a class, then create a top level lateinit Config and Config = Config() on startup 🤔

[david-wg2]

or provide the object with a init() method

[Big Chungus]

Sounds like the initial idea with extra steps anyways

[david-wg2]

it feels like i’m missing something obvious

[david-wg2]

yeah

[Big Chungus]

I'd say use dependency injection instead

[Big Chungus]

And make Config a class that's injected where needed

[Big Chungus]

Have a look at Kodein

[Big Chungus]

Quite simple to grasp and is kotlin-oriented. Also has a neat integration with ktor if you;re using it

[david-wg2]

thanks, will have a look

[Big Chungus]

You can have a look at my sample project for example setup: https://gitlab.com/kotlin-examples/transaction-api

[Big Chungus]

Uses ktor, kodein and spek for tests

[Casey Brooks]

Objects shouldn’t really be used for holding global state like this, because they can’t reliably track with the application lifecycle (by nature of being global). By wanting to have the object initialized at a specific time, you’re tying it to the application lifecycle.

Dependency Injection is definitely the way to go here, for managing lifecycle-aware “global” objects.

[Jørund B. Fagerjord]

I'm sorry for being thick, but is what you're saying that the config object will live throughout the application lifecycle, and it shouldn't (because that's wasteful use of memory)?

[Jørund B. Fagerjord]

You can have the Kodein object being statically available (in Android, for example, it is common to use a property of the Application object)

https://kodein.org/Kodein-DI/?6.3/getting-started

Wouldn't this also have the same memory footprint?

[Jørund B. Fagerjord]

But I agree it makes sense if you're already using dependency injection