That's *really *not what you're supposed to use a context for. If you just want a grab bag for random values (and really, you don't), you can just use a map.
A context is for sharing scoped data across APIs, threads, and other boundaries. The documentation says "request scoped" but that term can be a lot broader than simply a web server. I think that in this use, "scoped" means neither above nor below the scope of a request. Values stored within a context should be things like a requestUUID, which can be used to trace the request through the graph of your system, and even out into foreign systems, if they adapt themselves to accept some sort of context object. Or, it can be used to share a cancelation channel, which can be used to cancel any running go routines within the scope of the context. To do this without a context, you'd need to pass the cancel channel from one function to the next. With a context, you can group these very specific things into a convenient wrapper. You really don't want to start overloading that wrapper. Do you *really *want your user credentials available to every part of the system that your request touches? No. But you would probably like to have a cancelation channel available. If you just want a thing that you can shove random data into, there are plenty of other data structures available. A seriously caution you against going that route though because it only leads to misery. On Wednesday, June 8, 2016 at 11:54:48 PM UTC-4, Ian Lance Taylor wrote: > > On Wed, Jun 8, 2016 at 7:44 PM, <jonathan...@gmail.com <javascript:>> > wrote: > > > > Is storing user credentials in Context part of it's intended use? > > > > In my case there would be validation of the credentials and then storing > > more information in the context. > > For something like a web server that serves requests for many users, > yes, storing user credentials in a Context would be a normal use. > > > There seems to be a pretty gray line as to what should be a parameter > and > > what should go into Context? > > Yes. A Context can always be replaced by a list of arguments. In > general, for something like a web server, it's reasonable to put > everything that is specific to a single request into a Context. That > gives you a single value you can pass around. It's particularly > useful for deadlines and for gathering request- or user-specific > stats. In a large server, the advantage of a Context is that you can > add additional values as they become useful, without having to plumb > them through everywhere (because you've already plumbed the Context > everywhere anyhow). > > Ian > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
