3 ms·
> The compiler can tell if something isn't referenced - but it can't tell if a provider that goes into a DI framework is never invoked. It sort of can though.
by james_s_tayler 7y ago
> The compiler can tell if something isn't referenced - but it can't tell if a provider that goes into a DI framework is never invoked.
It sort of can though. It depends on the circumstance. If there is an interface with one implementation or even multiple implementations and that interface isn't referenced anywhere nor are any of its references then you can reason that those dependencies might be provided to the DI container but will never be requested as they can't be. In that case - delete them.
In the case where you have one interface which has multiple implementations and the interface is referenced, I agree. Nothing will tell you if there is one implementation sitting there entirely unused forever.
If you wanted to solve that problem you probably could. In practice I don't find it a big issue.
- vkou 7y ago1. The interface may not be referenced within the particular scope of an injector. Scopes (and the modules that make up an injector) are determined at run-time, so the compiler has no idea whether or not the injector that generates ParentWidget needs FooModule, or not. As long as an object sharing an interface with something that FooModule produces is injected anywhere else in your application, for any reason, you can't statically figure out that you should remove it from the injector that creates ParentWidget. 2. The interface is referenced, the implementations might not even be bound to it, depending on run-time conditions. Even trivially scoped dependency injection is a fantastic way to make it impossible for your compiler, and very hard for a human, to reason about your dependencies.