4 ms·

Most of these things can be done with higher-order functions too. I think that if Java had had lambdas earlier, Spring and other such frameworks might look ver

Most of these things can be done with higher-order functions too. I think that if Java had had lambdas earlier, Spring and other such frameworks might look very different. You can see that already, Spring is adding (experimental?) support for more declarative styles of configuration instead of the rather slow and hard-to-debug reflection magic: https://github.com/spring-projects-experimental/spring-fu https://github.com/spring-projects-experimental/spring-fu

cztomsik 5y ago
Yes but unfortunately I don't see how it invalidates my point. a) you either replace DIC with custom hard-wired functions (composed using any-order custom helpers) and then it's still hard-wired at one place b) you reinvent DI with functions but it's still some magic, late-configurable, easy-to-plugin container (aka the circus which I think you were referring to and which I have said it's actually useful and worth) EDIT: or what exactly are you complaining about?
- Tainnor 5y ago
  Yes, you do need a certain level of indirection to achieve the things you mentioned without polluting your code with non-business concerns such as transactionality. But the key differences are: 1. Application startup is faster because you avoid reflection. 2. It's type-safe because you avoid reflection, so you get compile-time errors instead of startup errors (or worse, startup errors only in certain configurations). 3. It gives you more inspectable behaviour. You can see how the entrypoint of the application wires together components. A lot of this can be hidden, spread out over multiple places and hard to understand otherwise. Also, I'm not the person you originally replied to, didn't call DI a circus, and actually think that DI is a useful concept per se (that some FP purists maybe under-appreciate): It could just IMHO be done in a cleaner way (and a more deliberate way, not everything needs to be wrapped in 5 layers :)) with functional constructs instead of reflection hell. :D
  - cztomsik 5y ago
    Oh, sorry for my misunderstanding then, I thought you were OP. 1. that's... not a problem for me 2. fair but you have tests & pipelines, so not a problem... for me :) 3. this is kind of fair, yeah 4. I absolutely agree about unnecessary layers, java engineers are the worst when they learn about something new and don't have enough practice yet

cztomsik 5y ago

Yes but unfortunately I don't see how it invalidates my point. a) you either replace DIC with custom hard-wired functions (composed using any-order custom helpers) and then it's still hard-wired at one place b) you reinvent DI with functions but it's still some magic, late-configurable, easy-to-plugin container (aka the circus which I think you were referring to and which I have said it's actually useful and worth) EDIT: or what exactly are you complaining about?

Tainnor 5y ago
Yes, you do need a certain level of indirection to achieve the things you mentioned without polluting your code with non-business concerns such as transactionality. But the key differences are: 1. Application startup is faster because you avoid reflection. 2. It's type-safe because you avoid reflection, so you get compile-time errors instead of startup errors (or worse, startup errors only in certain configurations). 3. It gives you more inspectable behaviour. You can see how the entrypoint of the application wires together components. A lot of this can be hidden, spread out over multiple places and hard to understand otherwise. Also, I'm not the person you originally replied to, didn't call DI a circus, and actually think that DI is a useful concept per se (that some FP purists maybe under-appreciate): It could just IMHO be done in a cleaner way (and a more deliberate way, not everything needs to be wrapped in 5 layers :)) with functional constructs instead of reflection hell. :D
- cztomsik 5y ago
  Oh, sorry for my misunderstanding then, I thought you were OP. 1. that's... not a problem for me 2. fair but you have tests & pipelines, so not a problem... for me :) 3. this is kind of fair, yeah 4. I absolutely agree about unnecessary layers, java engineers are the worst when they learn about something new and don't have enough practice yet