Hey, folks! I developed a little-config and powerful dependency injection framework! <https://shawxi...

# feed

[Shawxing Kwok]

Hey, folks! I developed a little-config and powerful dependency injection framework!
https://shawxingkwok.github.io/ITWorks/docs/jvm/tracer/usage/annotations/

[Javier]

I think the need to implement generated interfaces will block its adoption

[LeoColman]

I'd love to see a comparison between Tracer, Koin, KodeIn and Dagger/Hilt.

I know there is

Tracer has several main advantages over common DI tools, as listed below:

Minimal configuration. Powerful: generic types and variances are parsable, and it can trace super types as well.

But it's a bit too abstract for my mind

[Shawxing Kwok]

1. It's certainly a disadvantage for Tracer to implement generated interfaces. I hope one day Tracer is integrated into Kotlin system as the new syntax.
2. It's too long to make a true comparison. In a big project, Koin, KodeIn, Dagger/Hilt should care about lifecylcles, and maybe dependency cycles further.

[Javier]

Snippet about that new syntax?

[Shawxing Kwok]

message has been deleted

[Javier]

root class House

nodes(House)
class Bedroom{
    val bed = Bed()
}

tracer(Bedroom)
class Bed{
    private val house get() = __House
}

[Javier]

I doubt a lot they add those keywords if they didn’t even add a new keyword for Compose

[Stefan Oltmann]

I feel Annotations as compiler instructions serve a purpose here an I'm fine with how it is with Compose

[Shawxing Kwok]

There is no need for Compose to do this. With my expected Tracer syntax, there hints you to build when you finish inputting nodes class Bedroom and makes Bedroom implement BedroomTracer automatically.

Although context receiver is not adaptable on Kotlin-JS and Kotlin-Native at present, they are realizable theoretically.

[Javier]

Anyway, context receivers doesn't provide you that syntax?

class House

context(House)
class Bedroom {
    val bed = Bed()

    // generated somewhere
    val __House get() = this@House
}

context(Bedroom)
class Bed {

     // generated somewhere
     private val __House get() = __House
}

[Javier]

Although context receiver is not adaptable on Kotlin-JS and Kotlin-Native at present, they are realizable theoretically.

That is because it isn't finished yet, the final implementation will work with all targets

[Javier]

With my expected Tracer syntax, there hints you to build when you finish inputting nodes(Bedroom) and makes Bedroom implement BedroomTracer automatically.

You don't need a new keyword for that anyway, an annotation is enough

[Shawxing Kwok]

context(Bedroom) keeps the same. But @Nodes class Bedroom : BedroomTracer changes to nodes class Bedroom. Next Kotlin plugin hints at you to build.

[Javier]

nodes(Beedroom) Bed would be exactly the same as @Node context(Bedroom) class Bed inside a compiler plugin if I am not missing anything. No need for a new keyword.

[Javier]

You can add any supertype you want automatically based on an annotation, in this case, @Node

[Shawxing Kwok]

You can add any supertype you want automatically based on an annotation, in this case, @Node

It's different from your expected compiler plugin. Because the interface generates after building.

[Javier]

That is not correct, with K2 you can add the supertype in frontend (FIR)

[Shawxing Kwok]

That is not correct, with K2 you can add the supertype in frontend (FIR)

[Javier]

And, you are able to generate the structure of those interfaces in frontend too.

[Shawxing Kwok]

That is not correct, with K2 you can add the supertype in frontend (FIR)

Ok, I will learn further and optimize Tracer. Thx!

[Javier]

Main issue is you can do that with KSP, you need a compiler plugin using K2

[Shawxing Kwok]

Main issue is you can do that with KSP, you need a compiler plugin using K2

Got it! I appreciate your help.