Is there a cleaner way to set a top-level variable later in code without making it a lateinit var?

Question

So what I want to achieve is that to have the top-level variable set some time later in the main function, but I don't want to make it a lateinit var which certainly breaks the Extension variable functionality.

For instance this code doesn't work since extension variables don't support lateinit modifier:

lateinit var Dispatchers.Konvironment: MainCoroutineDispatcher
    private set

fun main() {
    ...
    Dispatchers.Konvironment = ArbitraryMainDispatcher(Thread.currentThread()) { queue.add(it) }
    ...
}

So what I finally came up with is to use a dummy variable and implement the getter of the val variable.

val Dispatchers.Konvironment: MainCoroutineDispatcher
    get() = dispatcher

private lateinit var dispatcher: MainCoroutineDispatcher

fun main() {
    ...
    dispatcher = ArbitraryMainDispatcher(Thread.currentThread()) { queue.add(it) }
    ...
}

But it is certainly not clean way to do that. It looks ugly (ish) creating multiple variable in the top-level structure is not very clean architecture.

So is there any possible clean workarounds? Sort of like lazy initialization, by some delegates or something.

Answer 1

Well, partially answering your question:

var Dispatchers.Konvironment: MainCoroutineDispatcher
    get() = dispatcher
    private set(value) {
        dispatcher = value
    }

private lateinit var dispatcher: MainCoroutineDispatcher

fun main() {
    ...
    Dispatchers.Konvironment = ArbitraryMainDispatcher(Thread.currentThread()) { queue.add(it) }
    ...
}

will give you the desired way of assigning the value. There is no way to get rid of this additional lazyinit variable, though.

Extensions are nothing more than just some Kotlin syntax sugar for static methods which take an instance of the extended class as one of the arguments, and perform some action. If you're familiar with Java then, for example, these extensions:

// Extensions.kt

fun Foo.extendedAction() {
    println(this)
}

var Foo.extendedBar: Bar
    get() = this.bar
    set(value) {
        this.bar = value
    }

are under the hood these methods in Java:

public class ExtensionsKt {
    public static final void extendedAction(Foo foo) {
        System.out.println(foo);
    }

    public static final Bar getExtendedBar(Foo foo) {
        return foo.getBar();
    }

    public static final Bar setExtendedBar(Foo foo, Bar bar) {
        foo.setBar(bar);
    }
}

The conclusion which maybe drawn from the above is that extensions don't actually add anything to the extended classes' signatures, they simply decorate them with additional functionality. Or, as put in the docs:

Extensions do not actually modify classes they extend. By defining an extension, you do not insert new members into a class, but merely make new functions callable with the dot-notation on variables of this type.

So you can see, unless dispatcher somehow already exists within Dispatchers, you can't do what you want without providing an external, "backing" variable which value can be actually referenced by the extension.