3 ms·
I really disagree with this. A function taking a Context is a really important signal to me about the semantics of that function. I also much prefer being able
by cle 3y ago
I really disagree with this. A function taking a Context is a really important signal to me about the semantics of that function. I also much prefer being able to see context values explicitly passed around, instead of values that magically appear out of the ether, without a clear code path to find out where they came from, what goroutine it's bound to, where that goroutine came from and its lifecycle, etc.
- eweise 3y agoThe context is just a big bag of stuff. you don't know what's really in it. Ends up almost any method that needs something from the big bag ends up having a context parameter, but you don't know why that method needs it.
- cle 3y agoSeparating these concerns (cancellation vs. bag-of-request-scoped stuff) might make sense. I'm specifically talking about the cancellation side of contexts. I don't think there's a good answer to this other problem of whether those two concerns should be combined into one mechanism, the options that I know about all have mixed tradeoffs. I still think an explicit bag-of-stuff is better than an implicit one though.
- eweise 3y agoBelieve me I've tried to write Go code that doesn't follow the Go conventions and can't get my PRs approved even with tiny differences. So the idea that I could separate these two concerns might be a good one, but in practice it would be impossible.
- skybrian 3y agoRight, you don't know what's in it, but you know you need to forward it if you start a goroutine.
- eweise 3y agoI also need to forward it to nonroutines because there is a logger in the context and almost every function wants to use the logger. So essentially, we have to almost alway pass context as the first argument to any function unless its some private function trivial function.
- jakjak123 3y agoYes, but I will curse everyone who didnt pass the logger so we lost the logcontext :(
- badrequest 3y agoTreating a context value as a bag to fetch data out of is the first mistake. They should only ever be used to control things like deadlines and whether or not a part of a function executes. IMHO they should disallow attaching values to a context.
- jakjak123 3y agoYes/no/maybe? context is one of the few ways to get contextual logging and tracing to work in a almost general way in Go. But I have also used it to pass the authenticated user to the handlerfunc. I dont dig it, but it works and avoids the need to keep a static map of request pointers somewhere to figure out which user was in this request...