A modern programming language that makes developers happier.

kotlinlang

Is there any way to shorten the boiler-plate required for binding singletons where all the dependencies are coming from Kodein e.g.

```// replace
bindSingleton { Foo(instance(), instance(), instance(), instance(), instance()) }
// with something like this
bindSingleton { ::Foo }```


Similar to this in <#C67HDJZ2N|koin>: <https://insert-koin.io/docs/reference/koin-core/dsl-update>

Actually, no. Not with using constructor parameter.
You could use the `DIAware` interface to manage on site retrieval instead of constructor injection

I don't like the `DIAware` approach because it ties my code to Kodein-DI. I'm a firm believer in the DI system being decoupled from the underlying code. I'd rather keep the boiler-plate.

How is the Koin team pulling this off? Are they using a compiler plugin or something?

this is ACTUALLY not possible with Kodein-DI

feel free to post an issue on github :wink:

<https://github.com/Kodein-Framework/Kodein-DI/issues/408>

No magic here 
<https://github.com/InsertKoinIO/koin/blob/3.2.x/core/koin-core/src/commonMain/kotlin/org/koin/core/module/dsl/New.kt|https://github.com/InsertKoinIO/koin/blob/3.2.x/core/koin-core/src/commonMain/kotlin/org/koin/core/module/dsl/New.kt>

I am not sure that we want to do the same. Defining a fixed number of function with N parameter is arbitrary. I have to think about it.

Makes sense. This pattern is not uncommon. For example, the Kotlin stdlib has `Function0` through `Function22`, and in fact the `::Foo` syntax returns a `KFunctionN`. Rxjava has <http://reactivex.io/RxJava/3.x/javadoc/index.html?io/reactivex/rxjava3/functions/Function5.html>. And so on.

Just tried it out with creating similar extensions for KodeinDI locally, and I have to admit, it does simplify the module definitions quite a bit.

Sounds fair. I’ll see when I will see what I can do to implement this.

<@U0NT624JZ> could you please post these extensions?

<@U01B5PR92QH>: <https://gist.github.com/rocketraman/84302f408d34576052e07589e9e90b26>

I've been very happy with it -- it really cleans up the module definitions, and often eliminates any diffs in the DI logic completely