Hey all. We're starting to land some Kotlin-specif...
# dagger
j
Hey all. We're starting to land some Kotlin-specific changes into Dagger! Two have already landed which will be in the next release: - Understand qualifier annotations on properties without requiring a use-site target (i.e.,
@Whatever
instead of
@field:Whatever
) - Understand
@Module
on
object
does not require a module instance. We have a few more in the pipeline, but if you have any ideas of small ergonomic improvements like this please file an issue on GitHub.
πŸ‘½ 2
πŸ‘ 9
❀️ 4
πŸŽ‰ 34
z
Is there any chance of ever getting to
@Inject
annotate the class declaration in order to specify the default constructor rather than having to break the constructor out?
πŸ‘Œ 1
j
The
@Inject
annotation does not allow targeting to types. You'd probably have better luck getting Kotlin to add an annotation use-site target for the primary constructor for class-level annotations.
βž• 1
z
gotcha, would that be something to post on their YouTrack?
j
Yes
z
Thanks. Happy to see some Kotlin QoL improvements in Dagger, though!
a
So the second one is about static provides?
j
Yes. Providers on an object will be interpreted as "static" without needing
@JvmStatic
.
πŸŽ‰ 10
πŸ‘ 4
πŸ‘Œ 6
The generated code now knows to call
Whatever.INSTANCE.method()
in that case.
And then R8 has a staticization pass which will likely eliminate the
INSTANCE
altogether and make them static in bytecode anyway. More details on that at https://jakewharton.com/r8-optimization-staticization/
πŸ”₯ 3
g
The need for
@JvmSuppressWildcards
is significantly decrease ergomonics, especially for lambdas
πŸ‘ 1
j
That's next on my list. Well, first. The listed two things were done by someone else.
πŸ‘ 5
g
typealias as qualifier, but it, I believe, already was reported
j
Yeah I'm not sure I quite buy that one
g
Yeah, also not sure about backward compatibility with existing code, but looks still nice to have super simple way to declare qualifiers. But anyway, looks that we use
@Named
much more than annotation because of multi-module project
p
Rename component and module into something less ambiguous πŸ˜‰