Other parts of our org use a DI framework and I feel like it causes a new class of dependency ordering bugs or missing dependencies. These just don’t exist when everything is passed in the ctor.
Other parts of our org use a DI framework and I feel like it causes a new class of dependency ordering bugs or missing dependencies. These just don’t exist when everything is passed in the ctor.
I've found there to be something radically compelling about all the hooks Spring allows into it's runtime. The sub-interfaces of Aware offer all sorts of ways to see what is in your runtime, see things getting constructed, see other parts of the lifetime of things.
Asking the container for a thing is the most well known use case, but there's so so much we can learn about our environment at runtime by having these managed containers. Programming used to hint at "Meta-Object Protocols", more expansive forms of objects, and Spring for example delivered us something like that: a higher level better modeled object (and factory and other pieces) than what the runtimes gave us.
DI addresses/can address/affects more than 10 different aspects of application lifecycle. We've described our reasoning in several talks linked at https://github.com/7mind/izumi?tab=readme-ov-file#docs
> I feel like it causes a new class of dependency ordering bugs or missing dependencies
That's precisely where phased approach shines.
Can you provide specific examples here instead?
What I think is most useful in cases like this is before-and-after code snippets showing how the library adds value.
Not in before-after form though, but there was that "I'll eat my hat" discussion exactly in this form: https://www.reddit.com/r/hascalator/comments/aigfux/comment/...?
I’ve worked in C++, C#, rust, and TypeScript personally so I really can’t comment on Java.
https://izumi.7mind.io/distage/basics.html#activation-axis
I feel like all you need there is a ctor param that takes a greeter and pass in whichever you want.
Those params can be cached as necessary or part of larger config POD objects if they are often passed with other dependencies.
Also you want to be able to make sure that your application will start without actually running it. In Scala implementation we do it at compile time for all the possible paths.