4 ms·

I don’t think I’ll ever understand the affinity for DI libraries. I write a lot of tested code but it’s always just plain old interfaces and constructor argumen

by tyleo 1y ago

I don’t think I’ll ever understand the affinity for DI libraries. I write a lot of tested code but it’s always just plain old interfaces and constructor arguments for me. 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.

pshirshov 1y ago
> I’ll ever understand the affinity for DI libraries 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 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.
- tyleo 1y ago
  I looked at the link you shared but it’s just a page of additional links. 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.
  - pshirshov 1y ago
    There are docs and examples here: https://izumi.7mind.io/distage/ https://izumi.7mind.io/distage/ 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/eeq43xj/ https://www.reddit.com/r/hascalator/comments/aigfux/comment/...?
    - ricardobeat 1y ago
      I assume the top comment was made in relation to TypeScript, not DI in general. A lot of this content explains how it improves on problems compared to Spring, and statements like 'there was no good way to create configurable apps' or avoiding use of Java reflections, which do not seem relevant to TypeScript/JS.
      - tyleo 11mo ago
        I meant my comment to be general but maybe Java is uniquely bad. I’ve worked in C++, C#, rust, and TypeScript personally so I really can’t comment on Java.
mrkeen 1y ago
Agreed. Modern Spring brags about not requiring pages of external XML files like it did in the old days. But plain constructors is still an improvement on both.
- pshirshov 1y ago
  Configurable apps (see "axis" and "role" concepts in distage) are prohibitevely hard to setup and maintain, dual test with sound opt-in memoization are, probably, practically impossible.
  - tyleo 1y ago
    So I looked at the examples and it just seems like a lot for a little. https://izumi.7mind.io/distage/basics.html#activation-axis 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.
    - pshirshov 1y ago
      No, you need much more because you want to switch multiple implementations at once, you want to avoid logical conflicts and you want to avoid specifying flags which are redundant in a particular configuration. 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.
- oweiler 1y ago
  It just gets rid of the boilerplate. Never had a problem with ctor injection in Spring.
jauntywundrkind 11mo ago
That's something DI does sure, but Spring for example is a fully managed way of talking about stuff in your app. It exposes universal APIs to talk about all the things, and the ways of making things, and config for things. It lets you see what stuff is made. 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.

by tyleo 1y ago

pshirshov 1y ago

> I’ll ever understand the affinity for DI libraries 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 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.

tyleo 1y ago
I looked at the link you shared but it’s just a page of additional links. 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.
- pshirshov 1y ago
  There are docs and examples here: https://izumi.7mind.io/distage/ https://izumi.7mind.io/distage/ 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/eeq43xj/ https://www.reddit.com/r/hascalator/comments/aigfux/comment/...?
  - ricardobeat 1y ago
    I assume the top comment was made in relation to TypeScript, not DI in general. A lot of this content explains how it improves on problems compared to Spring, and statements like 'there was no good way to create configurable apps' or avoiding use of Java reflections, which do not seem relevant to TypeScript/JS.
    - tyleo 11mo ago
      I meant my comment to be general but maybe Java is uniquely bad. I’ve worked in C++, C#, rust, and TypeScript personally so I really can’t comment on Java.

mrkeen 1y ago

Agreed. Modern Spring brags about not requiring pages of external XML files like it did in the old days. But plain constructors is still an improvement on both.

pshirshov 1y ago
Configurable apps (see "axis" and "role" concepts in distage) are prohibitevely hard to setup and maintain, dual test with sound opt-in memoization are, probably, practically impossible.
- tyleo 1y ago
  So I looked at the examples and it just seems like a lot for a little. https://izumi.7mind.io/distage/basics.html#activation-axis 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.
  - pshirshov 1y ago
    No, you need much more because you want to switch multiple implementations at once, you want to avoid logical conflicts and you want to avoid specifying flags which are redundant in a particular configuration. 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.
oweiler 1y ago
It just gets rid of the boilerplate. Never had a problem with ctor injection in Spring.

jauntywundrkind 11mo ago

That's something DI does sure, but Spring for example is a fully managed way of talking about stuff in your app. It exposes universal APIs to talk about all the things, and the ways of making things, and config for things. It lets you see what stuff is made. 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.