You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using Guice with Kotlin is annoying because Kotlin inserts implied wildcards. For example, this Kotlin code:
class Jesse {
@Inject var tacos: List<Taco>? = null
)
is equivalent to this Java code:
class Jesse {
@Inject List<? extends Taco> tacos;
}
Note that Kotlin’s List<Taco> is equivalent to Java’s List<? extends Taco>! And this is really annoying because it’s invisible in the source code.
I claim that nobody ever wants to differentiate between types with wildcards and similar types without. Ie. nobody uses both Key<List<? extends Taco>>, Key<List<Taco>> in the same application on purpose.
I’d like to implement an opt-in feature for Guice that canonicalizes keys to strip all wildcards from their types. If I implement such a thing, is anyone interested in code reviewing? It could remove a particularly annoying stumbling block from Google’s best dependency injector.
The text was updated successfully, but these errors were encountered:
Using Guice with Kotlin is annoying because Kotlin inserts implied wildcards. For example, this Kotlin code:
is equivalent to this Java code:
Note that Kotlin’s
List<Taco>
is equivalent to Java’sList<? extends Taco>
! And this is really annoying because it’s invisible in the source code.I claim that nobody ever wants to differentiate between types with wildcards and similar types without. Ie. nobody uses both
Key<List<? extends Taco>>
,Key<List<Taco>>
in the same application on purpose.I’d like to implement an opt-in feature for Guice that canonicalizes keys to strip all wildcards from their types. If I implement such a thing, is anyone interested in code reviewing? It could remove a particularly annoying stumbling block from Google’s best dependency injector.
The text was updated successfully, but these errors were encountered: