Implement new DSL for Factories instead of Providers only.

[Nek-12]

Similar to what is requested of Koin, we can implement a new and bindFactoryOf overloads that take not only the di instances into consideration, but also the parameters.

The way I envision it to work is:

1. During new invocation, it creates a holder which will contain flag consumed that specifies whether the parameters have been used already.
2. When the constructor is resolved, instead of using instance from DI directly, it first checks if a) the type of the argument matches the parameter type, and b) whether the parameters have not yet been consumed. If both are true, it provides parameters and marks them as consumed.
3. The next invocation proceeds. If the argument with type matching parameter type is encountered again, the parameters are not injected a second time. Instead, we should try to find them in the DI container this time or fail immediately.

This results in the same concise syntax bindFactoryOf being available for use.

Would you like me to open a PR for this feature?

P.S. I apologize for issue spam, we're migrating to Kodein and this is a great opportunity to ensure feature parity with Koin.

[Nek-12]

I have implemented a working solution in our repo.

@PublishedApi
internal interface ParameterizedNew {

    operator fun <T : Any> invoke(t: TypeToken<T>): T
}

@PublishedApi
internal inline fun <reified P : Any, T> DirectDIAware.parameterized(
    params: P,
    block: ParameterizedNew.() -> T,
) = object : ParameterizedNew {

    private val pType = generic<P>()
    private var consumed by atomic(false)

    @Suppress("UNCHECKED_CAST")
    override fun <T : Any> invoke(t: TypeToken<T>): T {
        if (consumed || !pType.isAssignableFrom(t)) return directDI.Instance(t, null)
        consumed = true
        return params as T
    }
}.run(block)

@PublishedApi
internal inline fun <reified T : Any> ParameterizedNew.invoke(): T = invoke(generic<T>())

public inline fun <T, reified P : Any, reified P1> DirectDIAware.new(
    param: P,
    constructor: (P1) -> T,
): T = parameterized(param) { constructor(invoke()) }

public inline fun <T, reified P : Any, reified P1, reified P2> DirectDIAware.new(
    param: P,
    constructor: (P1, P2) -> T,
): T = parameterized(param) { constructor(invoke(), invoke()) }

// 20 more overloads for new, +22 for factory and 22 for multiton.

I'm not sure how accurate it is, as I need to write tests for it when it is going to be moved to the main kodein repo. We will also need to settle on how to handle inheritance in the parameter injection. Using isAssignableFrom could be a more error-prone approach.

There is also an allocation overhead on each creation of a dependency because of the storage of the atomic consumed. This can be further optimized, but at the cost of less safety.

The resulting code looks like this:

    container<_, Params> { new(it, ::UserContainer) }

[romainbsl]

Of course PR are welcome !
We can iterate together on the subject obviously, let me know if you manage some time, if not I'll try to start from what you've done.

Just curious, from what library and why are you migrating ?

[Nek-12]

We're migrating from Koin. We're migrating because our team had enough with Koin.

Some reference:

• Scopes are broken in 4.1.0-Beta03 InsertKoinIO/koin#2106 - my last straw.
• Application is crashing when using koin outside SDK InsertKoinIO/koin#2103 - breaking changes for patch versions
• Koin bom does not contain koin-core-jvm dependency InsertKoinIO/koin#2092 - persistent publishing problems
• iOS Concurrent modification exception when closing a scope InsertKoinIO/koin#2058 - thread safety issues
• Constructor DSL named() doesn't create qualifier and therefore doesn't work InsertKoinIO/koin#1762 - faulty API decisions
• NoBeanDefFoundException in WorkManager InsertKoinIO/koin#1729 - crashes in production
• Constructor DSL prefers injecting over passing parameters and does not iterate over them. InsertKoinIO/koin#1456 - unsafe and faulty architecture, left unaddressed for 2+ years
• Ktor 3.0 support InsertKoinIO/koin#1716 - minor fix unaddressed for more than a year
• https://kotzilla.io/privacy - shady practices and revenue-centric development
• Recent drama with incorrect benchmarking setup and lack of response

Koin was #1 reason for crashes in our app and the sole cause of our low crash free session count.

I am glad that we don't have any crashes anymore with Kodein so far.