<@U4UGS5FC7> I was looking at this <example of kotlin di> that you wrote. I was wondering, if there...

# arrow

[julian]

@raulraja I was looking at this example of kotlin di that you wrote. I was wondering, if there was a requirement that Module.data or Module.domain be lazy evaluated, would there still be a way to have Module implement Data and Domain?

[raulraja]

Yes you may use functions or lazy properties as delegates:

[raulraja]

Untitled

[raulraja]

But the moment you instantiate the Module they will be called.

[raulraja]

So it's the same really. What is your use case?

[julian]

@raulraja Thanks. No specific use case. I was just comparing this technique of DI with Dagger, which offers lazy instantiation. Figuring out the pros and cons of using one vs the other.

[julian]

It's not such a big loss if we can't have Module implement Data etc when we require that values providing the implementations must be lazy. We could do:

val data: Data = Eval.later { InMemoryData() }
class data Module(val data = Eval<Data>, ...)
fun main() {
    with(Module.defaultInstance.data.value) {
        // Use Data as we would have if Module had implemented Data.
    }
}

[raulraja]

Right, you can always replace the inheritance unification of the uber module by composition if you don’t mind the extra wrapping or indirection