|
luchadornado posted:If Guice is "spaghetti", what is using Spring/Micronaut for DI? A pan of lasagna? This is why I thought it was a troll. Guice has potential to be probably the least "spaghetti" code framework or obfuscation of any DI solution I've used, Spring is way worse in my eyes.
|
#
?
Nov 23, 2021 00:05
|
|
|
|
| # ? May 28, 2024 23:16 |
|
|
As long as it's just c-tor injection. If you use property injection, you are a bad programmer and should go into management.
|
|
#
?
Nov 23, 2021 02:25
|
|
|
kayakyakr posted:Today sucked... And then today was good.  hell yeaaaa
|
|
#
?
Nov 23, 2021 02:32
|
|
|
Good Will Hrunting posted:This is why I thought it was a troll. Guice has potential to be probably the least "spaghetti" code framework or obfuscation of any DI solution I've used, Spring is way worse in my eyes. for the way guice is used sanely, its mostly just a stylistic preference over doing DI yourself. all of the more interesting stuff has turned out to not be worth it.
|
|
#
?
Nov 23, 2021 03:05
|
|
|
Good Will Hrunting posted:This is why I thought it was a troll. Guice has potential to be probably the least "spaghetti" code framework or obfuscation of any DI solution I've used, Spring is way worse in my eyes. Guice is the only DI framework I've ever used.
|
|
#
?
Nov 23, 2021 06:11
|
|
|
B-Nasty posted:As long as it's just c-tor injection. If you use property injection, you are a bad programmer and should go into management. Well that explains my most recent career move
|
|
#
?
Nov 23, 2021 06:22
|
|
|
B-Nasty posted:As long as it's just c-tor injection. If you use property injection, you are a bad programmer and should go into management. Why do you have to doxx me like that on these forums, that's not cool at all no but seriously what's wrong with it? is scrolling ugly or something?
|
|
#
?
Nov 23, 2021 15:20
|
|
|
Love Stole the Day posted:Why do you have to doxx me like that on these forums, that's not cool at all https://blog.ploeh.dk/2011/05/24/DesignSmellTemporalCoupling/ Also, depending on your language/DI container, property injection may require you to take a dependency on your DI framework in your core code, which shouldn't happen. If Oliveoil wants to NEW up your services in their DI-free app, they should be able to.
|
|
#
?
Nov 23, 2021 16:14
|
|
|
Love Stole the Day posted:no but seriously what's wrong with it? Conversely - what value are you getting from it, and is that worth the extra time effort to implement and understand the reliance on this library? A lot of poo poo works and doesn't seem too bad, but it can be death by 1000 cuts. People getting too clever with DI happens pretty frequently, and is entirely avoidable.
|
|
#
?
Nov 23, 2021 16:38
|
|
|
I feel like the obvious problem with a DI framework is it's more to think about and makes things frustrating. The less obvious problem is it's more to think about but you like it for some weird reason and don't realize that you're making subtle mistakes because you don't understand it as perfectly as you think. And those mistakes are going to piss off the people who have to work with them.
|
|
#
?
Nov 23, 2021 16:41
|
|
|
Love Stole the Day posted:Why do you have to doxx me like that on these forums, that's not cool at all It makes it hard to new up instances in a DI-less environment, like in tests or if you're providing lib code to other services. I don't want to gently caress with DI in my tests, and I know there are ways to inject mocks for field injection, but I'd really rather not and just get a public ctor to work with instead. Simpler and clearer what's going on, with more explicit failures. Guinness fucked around with this message at 19:17 on Nov 23, 2021 |
|
#
?
Nov 23, 2021 19:14
|
|
|
Do you people pronounce "ctor" the way you write it? Took me a second to realize what is being talked about. e: "c9r" gbut fucked around with this message at 21:38 on Nov 23, 2021 |
|
#
?
Nov 23, 2021 21:32
|
|
|
oliveoil posted:I feel like the obvious problem with a DI framework is it's more to think about and makes things frustrating. It's more like the frameworks just give you enough rope to hang yourself. I've used a lot of different DI libraries because I do a bunch of .net, and if you just stick to the basic functionality, (e.g. constructor injection and a startup method or file that registers all the dependencies), it's usually very quick to get a project to use a DI framework, and doing so has refactoring benefits (e.g. what if I decide later that a class should or should not be a singleton, or should only live through the lifetime of a request.) Where it goes wrong is that generally the frameworks will provide fancy functionality that is unnecessary and complicates stuff, like auto-registration of classes based on name. Every problem I've had with DI frameworks involved people loving with features they shouldn't have hosed with.
|
|
#
?
Nov 24, 2021 00:43
|
|
|
Bruegels Fuckbooks posted:Every problem I've had with DI frameworks involved people loving with features they shouldn't have hosed with. Quoting this to the moon.
|
|
#
?
Nov 24, 2021 00:46
|
|
|
Then there are insufferable types who come up with their own little DI frameworks they conjured in their free time and try to inject it (lol) in every work related project they touch.
|
|
#
?
Nov 24, 2021 00:57
|
|
|
Bruegels Fuckbooks posted:It's more like the frameworks just give you enough rope to hang yourself. I've used a lot of different DI libraries because I do a bunch of .net, and if you just stick to the basic functionality, (e.g. constructor injection and a startup method or file that registers all the dependencies), it's usually very quick to get a project to use a DI framework, and doing so has refactoring benefits (e.g. what if I decide later that a class should or should not be a singleton, or should only live through the lifetime of a request.) Where it goes wrong is that generally the frameworks will provide fancy functionality that is unnecessary and complicates stuff, like auto-registration of classes based on name. Every problem I've had with DI frameworks involved people loving with features they shouldn't have hosed with. Okay, yeah, when I used guice there were a few things that involved more than just constructor injection. Iirc there was a library we needed that required us to define a few our own guice annotations or something at some point, but it's been so long I can't remember.
|
|
#
?
Nov 24, 2021 01:19
|
|
|
My fave DI failure is when people convert singleton-registry style stuff over because DI Is Good, but never actually try and untangle the optional dependency graph and produce this kind of thing:
|
|
#
?
Nov 24, 2021 01:20
|
|
|
Those Magento agencies make so much money doing the worst things possible
|
|
#
?
Nov 24, 2021 01:23
|
|
|
Bruegels Fuckbooks posted:auto-registration of classes based on name Auto (convention) registration is almost a requirement on any sufficiently large application that is strict about only taking dependencies on abstractions. I sure don't want to be manually adding a line in my DI config for every FooService/IFooService pair I create; that's just brainless work. Most decent containers will throw errors in auto-registration if there are ambiguous concrete types, so those would be done manually.
|
|
#
?
Nov 24, 2021 02:37
|
|
|
B-Nasty posted:Auto (convention) registration is almost a requirement on any sufficiently large application that is strict about only taking dependencies on abstractions. I sure don't want to be manually adding a line in my DI config for every FooService/IFooService pair I create; that's just brainless work. Most decent containers will throw errors in auto-registration if there are ambiguous concrete types, so those would be done manually. just write the three lines of code
|
|
#
?
Nov 24, 2021 02:48
|
|
|
FamDav posted:just write the three lines of code Magic, convention-over-config is fine everywhere else, but no, not in my DI container. That must remain pure. Hundreds of manual registrations where a simple rule-based convention would work is way better than only manually registering the exceptional or tricky cases.
|
|
#
?
Nov 24, 2021 03:44
|
|
|
B-Nasty posted:Magic, convention-over-config is fine everywhere else, but no, not in my DI container. That must remain pure. Hundreds of manual registrations where a simple rule-based convention would work is way better than only manually registering the exceptional or tricky cases. Who is arguing for magic everywhere else?
|
|
#
?
Nov 24, 2021 03:46
|
|
|
Here's the only "magic" in our DI config: - If you ask for a concrete class, and that class is set up to be injectable, you'll get a newly-constructed instance of that concrete class. Anything else (e.g. you want someone who injects an interface to get an instance of the only concrete implementation of that interface)? Go write a binding. Simple, easy to understand, absolutely no "convention over configuration" nonsense.
|
|
#
?
Nov 24, 2021 03:59
|
|
|
it might be fine if the di container was like dagger where i got a nice compile time artifact that told me what the heck was going to happen, but otherwisepokeyman posted:Who is arguing for magic everywhere else?
|
|
#
?
Nov 24, 2021 04:00
|
|
|
My team didn't use any startup DI magic for a long time. Eventually we started hitting a few issues: * main.cc grew larger and less maintainable, to the point where it contained non-trivial logic that wasn't covered by unit tests. This less-tested code resulted in a few near misses and minor outages. * In our test setup helper library, we had a sort of structural mirror of main.cc's startup logic. It wasn't exactly identical. Most of the time the differences were just ownership / lifetime semantics (stack vs heap), but other differences were more meaningful, leading to confusion. * If some class is constructed in 10 different unit tests, and you need to add a new parameter to the constructor, then you have to update it everywhere. Annoying. If every test calls MagicBuild<MyClass>(), implicitly using the same startup logic as the real process, then this problem goes away. You *could* solve these problems without adopting any new DI patterns, but I found the tools helpful in this case. It helps that almost none of our classes are interfaces, and the "magic" is just writing a BuildMyClassFromCommandLineFlags() function and registering that factory function with the framework. I also get lost and confused quickly whenever I have to dig into a Guice codebase, but I'm sure some of that is just unfamiliarity on my part.
|
|
#
?
Nov 24, 2021 04:53
|
|
|
pokeyman posted:Who is arguing for magic everywhere else?
|
|
#
?
Nov 24, 2021 11:21
|
|
|
gbut posted:e: "c9r" i like it
|
|
#
?
Nov 24, 2021 12:32
|
|
|
Illusive gently caress Man posted:My team didn't use any startup DI magic for a long time. Eventually we started hitting a few issues: That sounds kinda reasonable. Maybe if you have a big monolith and your setup code is so complicated that it is a source of bugs, a DI framework might help. I kind of wonder if that indicates a testing problem or if splitting the monolith would be ideal, but maybe DI is the right choice? In my case I think I remember more: an in-house library or plugin ("module"?) for an in-house framework (written by two unrelated teams), both of which used guice. So I had to learn about guice to get it working and it wasn't straightforward imo and the tests were ugly and confusing to set up. I managed to isolate guice usage to just the parts required by the framework but it would have been nicer without any guice at all.
|
|
#
?
Nov 24, 2021 12:40
|
|
|
if it's a guice module you literally just say "hey use this module" when setting up your injector and it just works, anything else means you probably overcomplicated it for testing you just create a module with the fakes you want to use and install that instead
|
|
#
?
Nov 24, 2021 13:55
|
|
|
i've definitely seen people spend 10x the effort trying to avoid learning a DI framework while complaining that it's hard to understand, than it would have taken them to just read the docs and figure out how to do it properly
|
|
#
?
Nov 24, 2021 13:57
|
|
|
pokeyman posted:Who is arguing for magic everywhere else? Fair enough... Nobody did here, I suppose. I just get touchy when people claim that DI containers (with or without auto-reg) introduce way too much abstraction/magic. Meanwhile, they're working in a high-level language likely with some monstrosity of a web framework that has far more convention-based magic.
|
|
#
?
Nov 24, 2021 14:56
|
|
|
I've had really bad experiences with DI frameworks. The people that push them tend to try to use them for too much or overcomplicate design and testing to shove them into things. In general I think they're better avoided.
|
|
#
?
Nov 24, 2021 15:00
|
|
|
leper khan posted:I've had really bad experiences with DI frameworks. The people that push them tend to try to use them for too much or overcomplicate design and testing to shove them into things. Those people would overcomplicate designs with or without DI frameworks. If anything, a DI framework would allow one to simplify design, make it easier for anyone new to the project to understand it and grasp who does what and how. The magic ... it's just "I want X, so here's an instance of X". The how, that's interesting and useful to know in general, but definitely not always required. As for Guice vs spring ... Spring is a big framework and extremely useful. But if one only needs the DI part of it then it's a waste, Guice or other libraries would be more appropriate. But it is, in my opinion, better to use Spring components than trying to marry together a bunch of separate libraries to achieve the same functionality.
|
|
#
?
Nov 24, 2021 15:40
|
|
|
Jabor posted:if it's a guice module you literally just say "hey use this module" when setting up your injector and it just works, anything else means you probably overcomplicated it Definitely involved modules but likely a little more. I was just doing what the docs said to do and it involved defining a few annotations and figuring out where to use them, which seemed pretty magical to me.
|
|
#
?
Nov 24, 2021 20:16
|
|
|
oliveoil did you get E7 or E8? Edit: I wonder what the highest level is itt some brag on their E10
|
|
#
?
Nov 30, 2021 03:51
|
|
|
E10 is fellow. I don't think you can hold that level and be terribly anonymous.
|
|
#
?
Nov 30, 2021 04:50
|
|
|
idk it'd be pretty easy for jeff dean or whoever to just hang out in the anime forum as DeafJeans and not mention computers. it's not like there's a law that you have to post about the poo poo you're famous(-ish) for
|
|
#
?
Nov 30, 2021 04:55
|
|
|
More oversight on my new team than previous team. Previously I was justed handed multiquarter projects and told to figure out what to do and make it happen. New team, this morning I got assigned a bug, need to take some data logged in one place and make sure it ends up in an extra place. TL tells me where the places to update are, I find out there are some new places not mentioned, I get told to spend 60 minutes digging into the new place, then we'll talk so he can keep me on course. So I do that, talk comes 60 minutes later, he tells me to update the first places that he mentioned at the start and then continue to dig into the new places afterward. Feel like I haven't had this much hand-holding since my first month of my very first job. Is this normal? It's my first bug on this team so maybe he's trying to be extra helpful but "spend x time on it, then report back, then do it this way, then do the other part" is surprisingly specific direction. oliveoil fucked around with this message at 19:53 on Nov 30, 2021 |
|
#
?
Nov 30, 2021 19:51
|
|
|
oliveoil posted:he tells me to update the first places that he mentioned at the start and then continue to dig into the new places afterward. Follow the requirements outlined in the ticket before you start making extra work for yourself.
|
|
#
?
Nov 30, 2021 20:05
|
|
|
|
| # ? May 28, 2024 23:16 |
|
|
Ensign Expendable posted:Follow the requirements outlined in the ticket before you start making extra work for yourself. I don't disagree. I'm more surprised that it was all laid out specifically. "Okay, spend this much time investigating, then report back"... "Okay now do this and this". I guess if I'm asking about stuff then that's an invitation for direction though. I guess it'll go away once I am more familiar with the codebase and don't have many questions anymore.
|
|
#
?
Nov 30, 2021 20:19
|
|