KTP draft specs

Kotlin Toothpick draft specs - WIP

Use delegate properties for field injection

We should not use annotations for field injection, instead we will use delegate properties. For example:

by ktp.inject() // default scope
by ktp.lazy() // lazy
by ktp.provider() // provider

Moreover, there should be a way to:

• Specify when to use the default scope and when to wait for a scope to be provided.
• Use a named injection.

Kotlin friendly API for

• Module and bindings definition (https://github.com/sporttotal-tv/toothpick-kotlin-extensions and https://github.com/stephanenicolas/toothpick/issues/305)
• Scope creation and “scope binding”.
• Configuration of injectable classes
  • Should we use the @Inject annotation? and where?
  • How to define the constructor to use
  • How to define a singleton
  • How to define in what scope an instance will be created

Generate code compatible with optional parameters (possible?)

WIP

Moreover, KTP will be based on TP 2.0 -> no registries (no configuration needed), incremental annotation processing, better scope annotations, … (https://github.com/stephanenicolas/toothpick/issues/315, https://github.com/stephanenicolas/toothpick/issues/225)

Something you miss? Any suggestion? Please comment 🙂

[PaulWoitaschek]

I think constructor injection is the preferred way for dependency injection on kotlin too. It’s explicit. You don’t have to run your tests to know you forgot dependencies when refactoring.

[code-twister]

@dimsuz constructor injections are indeed preferred in Java DI frameworks, and also when we’re talking about DI in general most of us think about JSR330. Not sure this applies to Kotlin though. I believe we should use the community brainpower to figure out something that’s more suited for Kotlin and what this language has to offer, rather than limiting ourselves to what DI meant for Java.

A DI framework is supposed to make dependency injection easy. KTP could be just that tailored specifically for Kotlin.

Also I think if you like how Toothpick for java works, I believe you could still use it in Kotlin it would just be a bit different (maybe more verbose) and you would depend on a Java module.