Everything that uses configuration files should report where they're located

Re:Everything that uses configuration files should report wh... by louzell on Sunday June 25, 2023 @11:33AM (#36469284)

It drives me nuts when systems are unnecessarily built with "magic DI" frameworks rather than initializer/constructor DI. Why is it so hard to pass a dep into the initializer? Make the initializer parameter a protocol/interface and you can pass a mock in at testing. And you can also grep the whole codebase for callers and find the exact concrete type passed in at runtime.

[ Parent | on HN ]

Re:Everything that uses configuration files should report wh... by inoffensivename on Sunday June 25, 2023 @11:42AM (#36469394)

IMO, automatic DI frameworks were a big mistake. An idea that looks useful at the time, but actually leads to spaghetti mess code that is harder to maintain than it would be without any automatic DI.

[ Parent | on HN ]

Re:Everything that uses configuration files should report wh... by erickf1 on Sunday June 25, 2023 @12:30PM (#36469946)

Agreed.

[ Parent | on HN ]

Re:Everything that uses configuration files should report wh... by flaminHotSpeedo on Tuesday June 27, 2023 @11:51AM (#36494566)

I agree, though I'd say in the more general case that overly flexible DI frameworks are the broader problem.

Designers will put much more thought into how best to interact with a framework, so start with a small, opinionated interface then consider extension feature requests on a case by case basis

[ Parent | on HN ]

Re:Everything that uses configuration files should report wh... by Blackthorn on Sunday June 25, 2023 @01:17PM (#36470505)

Eh, it's not like it's much easier to find the last turtle in python. Or C++ when people are extensively using patterns like PointerToImpl*, which can really obfuscate things.

[ Parent | on HN ]