<@U2JKKPMEE> is it planned to improve the experime...
# koin
j
@arnaud.giuliani is it planned to improve the experimental feature to avoid the usage of
get()
? it is recommended to not use in Android, maybe moving from reflection to some another alternative (arrow meta maybe?)
a
yes this my next big item, once released all the new API from 2.2.0
👍 2
with Kotlin compiler approach, no need to write
get()
anymore
also the othe side of that, is that we could verify graph on the fly
j
Insane, thank you for the answer 😄
👍 1
h
This is super interesting for me, is there any Info, any discussion or anything about that already? :) I would like to at least read about all you are doing for koin in this regard :)
f
found this to be very interesting and having a detailed explanation of pretty simple code https://medium.com/@heyitsmohit/writing-kotlin-compiler-plugin-with-arrow-meta-cf7b3689aa3e It reminds me of C macros or java aspects (from java spring) in some sense.
a
it’s actually in my open tabs 😄
f
I'm still trying to figure out what's the role of shadow in all of it, and performance implications in a large code base.
h
Do you mean shadow jar plugin in the Compiler plugin tutorial? the compiler plugin Implementation and all of its dependencies have to be passed into the compiler via arguments. Bundling all those things into a fat jar is easiest solution, which is exactly what the shadow plugin does. Kotlin libs that are provided by the compiler executable already are excluded from the shadow jar :)
f
shadow plugin seems to be able to do a lot more than that. Do you mean I could have used something like fatJar plugin instead of shadow?
h
Shadow plugin is also able to shadow dependencies, rename packages so that you can include dependencies in your package without causing naming conflicts. Not Sure if that feature is needed for a compiler plugin
f
yep, that was exactly my question 🙂
h
Ah okay, then i don't think a compiler plugin needs sth shadowed, there's nothing configured in the example,only exclusion