3 ms·

What this blog post does not address is the joy of configuring DI with XML files /s Isn't it bizarre how software developers have taken runtime DI to such extr

What this blog post does not address is the joy of configuring DI with XML files /s Isn't it bizarre how software developers have taken runtime DI to such extremes that it was considered a good idea to configure services in XML or YAML -- basically another language, that has to be parsed, can be malformed, etc?

duality 8y ago
The creators of Guice mention how configuring the dependency graph in Java was a big advantage it offers over older XML-based frameworks like Spring.
- douglasisshiny 8y ago
  Spring has allowed for java configuration for some time.
- vips7L 8y ago
  I've never configured Spring DI via XML and I've been a Spring dev for at least 2 years. It's always been via Java annotations and config classes.
lmm 8y ago
Early Java took a stupid decision to deliberately restrict expressiveness in the name of being "blue collar" (ironically enough Go largely retreads the same mistake). The result was a language so cumbersome that people would do anything to avoid having to write actual Java. Stupid policies at large companies that subject "configuration" changes to much less scrutiny than "code" changes compounded the problem. The decision to use XML was actually quite reasonable for many developers given the constraints at the time. Thankfully Java has mostly seen the light these days, adding generics, first-class functions, and good-enough multiple inheritance (though it still has very restricted and cumbersome metaprogramming - classes are not first-class, and the lack of HKT makes it very difficult to work with functions generically since you can't abstract over arity), and people are gradually realizing that this different environment warrants different choices. (Companies still have terrible policies about code versus "config" though).
dullgiulio 8y ago
I never understood this. DI is for deciding program behavior. That should be a user choice. I don't understand how final users are supposed to (1) write XML files instead of providing simple human readable CLI flags, (2) know the program internals and being able to type in fully qualified class names. $ ./my-server -reporting=email vs setting com.mycompany.package.subpackage.di.providers.abstract.ReportingProvider to com.mycompany.package.subpackage.di.providers.impl.EmailReportingProviderImpl. The whole DI is a wrong concept. Dependencies should be instantiated at top level (main function) and explicitly passed down the call graph as interface instances. DI breaks the call graph with (configurable) side effects. If you pass down dependencies explicitly you don't even need mocking frameworks for testing.
- spand 8y ago
  You are just refuting your own straw man. Passing dependencies also qualifies as DI and is for the benefit of the developer. Maybe you are only talking about DI frameworks or containers in which case I share some skepticism but in general the concept of DI is pretty sound.
jcelerier 8y ago
> Isn't it bizarre how software developers have taken runtime DI to such extremes that it was considered a good idea to configure services in XML or YAML -- basically another language, that has to be parsed, can be malformed, etc? well, then how do you do it ? what do you do if your client / boss tells you "I want to configure the plug-ins & classes availables in the software through some file editing without having to recompile anything" and your codebase is in C++ / Java / Go / D / Rust ...
- JetSpiegel 8y ago
  > what do you do if your client / boss tells you "I want to configure the plug-ins & classes availables in the software through some file editing without having to recompile anything" and your codebase is in C++ / Java / Go / D / Rust ... You compile all the (tested) combinations as static executables and shove them all into the release package.
- stabbles 8y ago
  Yes, in that case you probably need to parse a config file. But you might also encounter DI config files for specific environments, like development where you inject MockMailer, TrivialLogger and InMemoryDatabase instead of RealLifeMailer, CloudLogger and ActualDatabase.

duality 8y ago

The creators of Guice mention how configuring the dependency graph in Java was a big advantage it offers over older XML-based frameworks like Spring.

douglasisshiny 8y ago
Spring has allowed for java configuration for some time.
vips7L 8y ago
I've never configured Spring DI via XML and I've been a Spring dev for at least 2 years. It's always been via Java annotations and config classes.

lmm 8y ago

Early Java took a stupid decision to deliberately restrict expressiveness in the name of being "blue collar" (ironically enough Go largely retreads the same mistake). The result was a language so cumbersome that people would do anything to avoid having to write actual Java. Stupid policies at large companies that subject "configuration" changes to much less scrutiny than "code" changes compounded the problem. The decision to use XML was actually quite reasonable for many developers given the constraints at the time. Thankfully Java has mostly seen the light these days, adding generics, first-class functions, and good-enough multiple inheritance (though it still has very restricted and cumbersome metaprogramming - classes are not first-class, and the lack of HKT makes it very difficult to work with functions generically since you can't abstract over arity), and people are gradually realizing that this different environment warrants different choices. (Companies still have terrible policies about code versus "config" though).

dullgiulio 8y ago

I never understood this. DI is for deciding program behavior. That should be a user choice. I don't understand how final users are supposed to (1) write XML files instead of providing simple human readable CLI flags, (2) know the program internals and being able to type in fully qualified class names. $ ./my-server -reporting=email vs setting com.mycompany.package.subpackage.di.providers.abstract.ReportingProvider to com.mycompany.package.subpackage.di.providers.impl.EmailReportingProviderImpl. The whole DI is a wrong concept. Dependencies should be instantiated at top level (main function) and explicitly passed down the call graph as interface instances. DI breaks the call graph with (configurable) side effects. If you pass down dependencies explicitly you don't even need mocking frameworks for testing.

spand 8y ago
You are just refuting your own straw man. Passing dependencies also qualifies as DI and is for the benefit of the developer. Maybe you are only talking about DI frameworks or containers in which case I share some skepticism but in general the concept of DI is pretty sound.

jcelerier 8y ago

> Isn't it bizarre how software developers have taken runtime DI to such extremes that it was considered a good idea to configure services in XML or YAML -- basically another language, that has to be parsed, can be malformed, etc? well, then how do you do it ? what do you do if your client / boss tells you "I want to configure the plug-ins & classes availables in the software through some file editing without having to recompile anything" and your codebase is in C++ / Java / Go / D / Rust ...

JetSpiegel 8y ago
> what do you do if your client / boss tells you "I want to configure the plug-ins & classes availables in the software through some file editing without having to recompile anything" and your codebase is in C++ / Java / Go / D / Rust ... You compile all the (tested) combinations as static executables and shove them all into the release package.
stabbles 8y ago
Yes, in that case you probably need to parse a config file. But you might also encounter DI config files for specific environments, like development where you inject MockMailer, TrivialLogger and InMemoryDatabase instead of RealLifeMailer, CloudLogger and ActualDatabase.