Tracer: new dependency injection tool with little config


With Kotlin-JVM, KSP and little configuration, Tracer generates extensional properties oriented to interior traceable elements, which realizes dependency injection in a novel way.

Main advantages

  • Little-config
  • Powerful: generic types and variances are supported
  • Fast: no cache or rum-time reflection

Model sample


Transit from general code

to this tracer sample below.

See many more features on tracer.

1 Like

What is a typical use case for this framework? I see it as a tool that helps creating graphs of interconnected objects. I’m just trying to figure out some real world examples for it.

I find the phrase “dependency injection” very confusing here, because it doesn’t solve the same kind of problems as typical dependency injection frameworks. As a matter of fact, I think it is somehow the opposite of the dependency injection. The whole point of dependency injection is to make connections between objects loosely-coupled. Your framework does the opposite. Objects are very tightly-coupled, they reference other objects directly.

If we have a graph of 20 objects, then each of them have to “know” the whole object graph to be able to reference its dependencies. If we change anything in the graph, we move the router to another room, we have to adapt the code everywhere. Your original implementation of House was more loosely-coupled and easier to adapt to changes than when using your framework. LivingRoom didn’t know how to acquire its dependencies and this is good. After the change, it has to know how to find them.

It reminds me the service locator pattern, but with auto-generated object ids.

  1. When you need LivingRoom, type _Liv and you would get the whole hint.
  2. The renaming problem could be solved by an IDE plugin that has not come out yet. And I suggest fixing object positions at present.