yeah the types have to match exactly, you can do `...

# kotlin-inject

[evant]

yeah the types have to match exactly, you can do

@Provides @IntoSet fun provideFoo(): () -> Foo = { FooImpl() }

[evant]

would be open to support Set<() -> Foo> and Set<Lazy<Foo>> , dagger does do this

[dave08]

That would be nice 😃!

[evant]

https://github.com/evant/kotlin-inject/issues/186

[evant]

I think a reason this wasn't originally implemented is it doesn't work for @IntoMap but I think I could live with it

[dave08]

Oh... because you use the Pair so the instance is already initialized... I guess that's why other DIs use the @IntoMap("keyName") form instead...

[evant]

yeah dagger has it's whole dsl for providing keys in annotations

[evant]

really wasn't a fan because of how complicated & limiting it was, but there are trade-offs

[dave08]

I wonder if there's even any advantage to have that pair there in the first place... the whole DSL might not be necessary, but giving the option of having the name passed to @IntoMap might be good enough...

[evant]

the advantage is you can use any object as the key

[dave08]

The reason why I'm using kotlin-inject in this project is exactly about the simplicity of it 😃! Even with Square/Anvil, dagger2 is VERY intimidating...

The pair could stay for that (although maybe a @Provides @IntoMap fun providesFoo(@MapKey key: Bar): Foo would do the trick... AND allow lazy or provider lambdas but then we're going right back to re-implementing dagger....), but having the option of providing the key in the existing annotation would allow lazy or provider lambdas to work without complicating the DSL.

[evant]

right, but then is it really worth it when you can do

@Provides @IntoMap fun proviesFoo(): Pair<String, () -> Foo> = "key" to { FooImpl() }

?

[dave08]

That's a great idea!

But then, you can't choose whether you need a map of providers lazies or instances like you can for regular dependencies. You could even do that for regular non-map providers...

I guess you're right, for @IntoSet it would be easy to do this, for @IntoMap you could add a note in the README (and/or in the @IntoMap kdocs), that it isn't supported and that what you proposed could be done instead...