Koin Annotations is available: <https://medium.com/koin-developers/koin-annotations-c06c2b876ebe>

# koin

[arnaud.giuliani]

Koin Annotations is available: https://medium.com/koin-developers/koin-annotations-c06c2b876ebe

[kenkyee]

out of curiosity, why @Single instead of the more common @ Singleton annotation?

Rest looks great...less boilerplate w/ minimal build speed hit 🙂

[arnaud.giuliani]

you have the @Singleton available. It’s just to keep the same “semantic”

[Róbert Nagy]

Just tried this out. @arnaud.giuliani great stuff!

Improving Developer Experience 👍

One capacity that opens this annotations approach, is the possibility to analyze everything at compilation and prepare more content for you

Do you have an issue/plan/roadmap for the above?

[Róbert Nagy]

I suspect the dynamic structure of startKoin{ } has to be changed, but theoretically having something like

@KoinStarter(includes = myModules)
fun initKoin()

could work? Where the compiler just checks that the myModules graph is complete? (all dependencies have bean definitions)

Though probably having arguments/lambdas complicates maintaining the nice modular structure of Koin, possible solutions:
• Keep verification at the end consumer (base/app module, like Dagger 😕 )
• Have something like @Transient where these dependencies could be ignored?
Maybe having a thread for a possible API design would be nice

[arnaud.giuliani]

apart of having deep static analysis, even dagger won’t be able to see dynamic modules loading behavior

[arnaud.giuliani]

but yes, first approach would be to help flag all graph from annotated classes

[arnaud.giuliani]

with the “includes” features, we can follow links to other modules then