But it isn't...

The component is instanciated, not it...

I mean that's how it was originally envisioned, is that you'd have a graph of components each with their own scope:

@AppScope
@Component
abstract class AppComponent {}

@RequestScope
@Component
abstract class RequestComponent(@Component val parent: AppComponent) {}

I was able to reproduce the

Unresolved reference

bug in your sample: https://github.com/evant/kotlin-inject-samples/pull/3

I'm wondering whether https://github.com/evant/kotlin-inject/pull/162 is available in

0.3.8-SNAPSHOT

yet

q: are these two providers not supposed to be equivalent?

protected val RealHttp.bind: Http
  @Provides 
  @SomeScope 
  get() = this

@Provides
@SomeScope
fun http(real: RealHttp): Http = real

unfortunately, ksp's lack of v1.0.1 release with kotlin 1.5.31 is blocking me from compiling my project on android

I'm missing dagger modules in kotlin-inject. In theory it might work to create fake components as interfaces and let your root component implement it, but that causes issues because interfaces can only have public members. And most of the times in a gradle module I module internal dependencies that are used to create an object

Uh and the other big thing is freezing. I'm trying to migrate a manual service locator to kotlin-inject and it blows up because we need to freeze our di entry point and as LazyMap is using mutable state that's not wrapped in an IsoMutableMap that makes kotlin-inject effectively main thread limited 😕

I'm testing a very simple sample with kotlin-inject, and everything works including the codegen, however I can't reference any of the generated classes. For example if I have a

MainComponent

there is a generated

fun KClass<MainComponent>.create()

however I can't reference it from my code.

I'm noticing that stale generated code for classes that no longer exist aren't removed by kotlin-inject. Is this something that ksp is supposed to handle?

Is it possible to have a scoped child component that narrows the scope for a dependency? Example in thread.

Solved... it was because in Android there's debug and release using the assemble task... and for some reason it looks at both even though I have only the debug one in the source set instruction...

yeah the types have to match exactly, you can do

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

For a combination between maps and sets, you could wire something together but it would be a bit complicated

typealias Foo1 = Foo
typealias Foo2 = Foo

@Provides @IntoSet
fun foo1ForSet1(): Foo1 = ...
@Provides @IntoSet
fun foo2ForSet1(): Foo1 = ...
@Provides @IntoSet
fun foo1ForSet2(): Foo2 = ...
@Provides @IntoSet
fun foo2ForSet2(): Foo2 = ...

@Provides @IntoMap
fun fooSet1(set: Set<Foo1>): Pair<String, Set<Foo>> = "one" to set
@Provides @IntoMap
fun fooSet2(set: Set<Foo2>): Pair<String, Set<Foo>> = "two" to set

@evant Do you have any plans to add something like Dagger's

fun inject(someActivity: SomeActivity)

...? It's SO MUCH nicer than having to do the trick in the Android docs on kotlin-inject's Github repo...

Is it possible to add a

@Inject

to a typealias? My use case is where I have a type that I want to use in two different scopes:

class Foo

@AppScope
@Inject
typealias AppFoo = Foo

@ScreenScope
@Inject
typealias ScreenFoo = Foo

Currently I have to use provider functions, which is a lot more verbose, especially since I now need a component for those function:

@Component
abstract class FooComponent {
  @AppScope @Provides fun provideAppFoo() = AppFoo()
  @ScreenScope @Provides fun provideScreenFoo() = ScreenFoo()
}

(this example is contrived, but I do have an actual use case for something like this)

Is it OK to rely on a child component to provide a dependency? For example:

class ResolverWrapper(val resolver: ContentResolver)

@Component abstract class ParentComponent {
  @Provides fun providesContentResolve(context: Context) = context.contentResolver
}

@Component abstract class ChildComponent(
  @Component val parent: ParentComponent,
  @get:Provides val context: Context
) {
  abstract val wrapper: ResolverWrapper
}

The above works, but is it OK to rely on this behavior?

Does anyone have a sample to share of injecting a view model into an

@Composable

function? If I do it as I would for a non-composable function, I get a new view model every time my view is recomposed.

Anyone have a sample of a modular Android app using kotlin-inject, with different modules defining their own

@Components

forming a tree of dependencies? I'm modularizing an app previously set up with kotlin-inject, and I'm running into issues. I'm hoping that by looking at a working example I can avoid having to ask a bunch of questions.

Not currently for simplicity's sake. Did look at a bit but haven't found a way that has enough benefits to be worth saving just a line of code. If you are binding an impl to an interface the it's probably because you want to be using different impls in different places so you need to tie it to something, it can't just be global. Putting it in a component is a natural way to do that as you can have different components provide different impls for the same interface. Sure you could reverse it and do something like

@Binds(in = AppComponent::class)
@Inject
class MyImpl : Impl

but it just feels like shuffling things around? It's also nice to have them all in one place so you can override them all for tests (a common usecase for having multiple impls for an interface).

Hey question, how would people feel about removing the kapt back-end? It costs quite a bit to maintain and limits certain features which can only be done in ksp (like annotating properties). I'm curious if people are even using it?

@evant I noticed that kotlin-inject doens’t have any synchronization logic for native. This is quite error prone as objects might be created multiple times though they are scoped. What do you think about making use of a lock on native like implemented here? https://github.com/InsertKoinIO/koin/blob/1326329060e6b923f9a54873178e55cdddc4d99e/core/koin-core/src/nativeMain/kotlin/org/koin/mp/KoinPlatformTools.kt#L29

@evant WDYT about a ContributesXYZ functionallity in kotlin-inject, similar to what Anvil does? https://github.com/square/anvil I wouldn’t want to miss it as it really decouples the binding boilerplate, especially with multibindings.

Just released 0.5.0! https://github.com/evant/kotlin-inject/releases/tag/v0.5.0

@evant What do you think about adding an explicit @Assisted annotation? My developers get extremely confused with the implicit “last arguments in the right order” approach.

Second thing, slightly related. The typealias logic is also confusing everyone. Also it seems that it’s abusing language features: https://kotlinlang.org/docs/type-aliases.html

Type aliases do not introduce new types. They are equivalent to the corresponding underlying types.

I think a dedicated Qualifier annotation would make things simpler to everyone.

Btw @eygraber about that parent/child injection change. I had originally had a more permissive check to just try to find potential leaks when using scopes, but I ran into a few problems with it. 1. It had some holes, you could easily get around it by inserting an unscoped dep between 2 scoped ones and it would compile but still leak. I could try to fix it but I was worried that I would have to keep chasing issues like that. 2. Which leads to another problem which is the logic here was subtle and I think it would be hard to understand what is allowed vs what is not, vs the simpler model that you can only go 'up' the graph to parents and not back down. 3. I checked dagger and verified that it behaves the same way with it's subcomponents. Just letting you know how I landed where I did.

Also 0.5.1 is now released which fixes the artifact resolution issue on multiplatfom with 0.5.0 😅