5 ms·

How does having struct literals help with DI? Can you give an example?

weberc2 9y ago
The primary purpose of a DI framework is to alleviate boilerplate by offering a simpler mechanism for describing compositions than provided by the language. If a language already has a handy initialization/composition syntax, you don't get anything from a DI framework. Different frameworks have different bells and whistles, so this is a general point.
- openasocket 9y ago
  Again, I find for constructing things Golang is no more or less boilerplate-y than Java. Can you give an explicit example (like, with code) where Golang's struct literal syntax allows you to construct objects with less boilerplate than Java?
  - weberc2 9y ago
    Sure. Anything with hash map or list literals (heaven forbid a list of hash maps!), off the top of my head. I'm not near a computer or I'd type out the example.
    - openasocket 9y ago
      Well Java does have array literals. They don't have hash map literals, but I really don't use map literals very often in Go except for constants. And you can make a HashMap in Java in the same number of lines as Golang (though not for an array of hash maps). I really don't see that as a killer feature.
      - weberc2 9y ago
        Arrays aren't equivalent to slices in Go. Map literals are nice for things like the driver pattern (a map of strings to some interface type; the user specifies which driver implementation should be used to handle some input). It's not about the number of lines, it's about having a declarative initialization syntax. In other words, it's about the number of expressions. This isn't a killer feature, it jjust means Go requires less boilerplate when doing explicit DI, so the ROI offered by a DI framework is low. If you don't agree that initialization in Go requires less boilerplate, maybe you should be asking yourself what you gain from your DI framework?
        kasey_junk 9y ago
        DI frameworks were not originally introduced to replace boilerplate. They were originally intended to move the behavior changes provided by DI from compile time to configuration time. This was especially valuable when you are delivering enterprise software to sites you don't control and you need to support a wide array of integrations. They also happen to reduce boilerplate & DI can help with test-ability so they were adopted for that as well, but if you are only doing DI for tests and only using a framework to reduce lines of code it's a fairly widely accepted anti pattern. I believe your basic assumptions about DI are wrong. The reason it hasn't taken off in the golang world is that the kind of software it was used for is less common & if you are writing it you'd not use golang for a host of reasons, none related to initializer syntax.

The primary purpose of a DI framework is to alleviate boilerplate by offering a simpler mechanism for describing compositions than provided by the language. If a language already has a handy initialization/composition syntax, you don't get anything from a DI framework. Different frameworks have different bells and whistles, so this is a general point.

openasocket 9y ago
Again, I find for constructing things Golang is no more or less boilerplate-y than Java. Can you give an explicit example (like, with code) where Golang's struct literal syntax allows you to construct objects with less boilerplate than Java?
- weberc2 9y ago
  Sure. Anything with hash map or list literals (heaven forbid a list of hash maps!), off the top of my head. I'm not near a computer or I'd type out the example.
  - openasocket 9y ago
    Well Java does have array literals. They don't have hash map literals, but I really don't use map literals very often in Go except for constants. And you can make a HashMap in Java in the same number of lines as Golang (though not for an array of hash maps). I really don't see that as a killer feature.
    - weberc2 9y ago
      Arrays aren't equivalent to slices in Go. Map literals are nice for things like the driver pattern (a map of strings to some interface type; the user specifies which driver implementation should be used to handle some input). It's not about the number of lines, it's about having a declarative initialization syntax. In other words, it's about the number of expressions. This isn't a killer feature, it jjust means Go requires less boilerplate when doing explicit DI, so the ROI offered by a DI framework is low. If you don't agree that initialization in Go requires less boilerplate, maybe you should be asking yourself what you gain from your DI framework?
      - kasey_junk 9y ago
        DI frameworks were not originally introduced to replace boilerplate. They were originally intended to move the behavior changes provided by DI from compile time to configuration time. This was especially valuable when you are delivering enterprise software to sites you don't control and you need to support a wide array of integrations. They also happen to reduce boilerplate & DI can help with test-ability so they were adopted for that as well, but if you are only doing DI for tests and only using a framework to reduce lines of code it's a fairly widely accepted anti pattern. I believe your basic assumptions about DI are wrong. The reason it hasn't taken off in the golang world is that the kind of software it was used for is less common & if you are writing it you'd not use golang for a host of reasons, none related to initializer syntax.