[etamponi]

Thank you for this. I'd even say that dependency injection frameworks eliminate the most important thing of dependency injection: explicit dependencies.

[EdwardDiego]

But they're not though?

    class Foo(@Inject x: SomeType) 

Is still a class you can't instantiate without a correct instance of the given type.

(If you're talking about field injection, then I agree, that is the devil and must be purged with fire. Constructor injection or none.)

And when there's multiple instances of a given type available, a good framework refuses to guess. And I really like compile time DI for surfacing these errors far quicker than the traditional runtime approaches.

[mrkeen]

My problem is that 100% of the time, the chain of construction is as brittle as if you'd not used DI as all.

It's not that clear with Foo(SomeType). What I usually deal with is:

    AuthController(AuthService(UserService(UserRepo(Hikari(Postgres(..))))).

Now I just want to test that AuthService accepts/rejects a user based on whether they're in the system or not. I want to do something like:

    users = new Map<UserId, User>()
    auth = new AuthService(users::get)

> And when there's multiple instances of a given type...

(There should always be (in the case that you're writing a test for something))

> a good framework refuses to guess

I do too! I want to manually wire the classes inside main() in the usual case, and manually wire (different combinations) of classes in the tests.