3 ms·
Your first request is tricky because it can lead to issues down the road if done poorly, so it is hard to just give a quick example of it. I wrote about this su
by joncalhoun 10y ago
Your first request is tricky because it can lead to issues down the road if done poorly, so it is hard to just give a quick example of it. I wrote about this subject recently (see https://www.calhoun.io/pitfalls-of-context-values-and-how-to-avoid-or-mitigate-them/ https://www.calhoun.io/pitfalls-of-context-values-and-how-to... ) and there is a lot of info to cover. That said I could see value in doing an example and referencing a more in depth overview from the example.
Once you cover (1) most of the others fall into line. There is little reason to use context values outside of MW from my experience.
Re (3) - can you provide a link or example of what you mean?
(5) - again, can you elaborate? Are you referring to error types? Or just how the errors are rendered?
I ask all these questions because I write a lot about Go and I am interested in trying to make examples of these available, but I want to understand what you are asking for first.
- tptacek 10y agoCould you be a bit clearer about the "issues down the road" we're concerned about with overuse of context, or with use of context for non-request-scoped dependencies? The end of your article advocates a little bit for just accepting code reuse, and the getter/setter/subfunction thing comes perilously close to GoF Java style for my taste. Further: I have seen, routinely, on pretty much every project I've worked on, serious production faults from errors and omissions in duplicated code. I'm not sure I've seen equivalently serious production faults (really: any faults) in overuse of things like "context".