Unless you need to pass the Request, pass its Context. This eases the composition of functions across packages that all take Context parameters. On Thu, Jul 14, 2016 at 3:09 PM Tyler Compton <xavi...@gmail.com> wrote:
> Thanks for the responses. I've used contexts before and understand that > they do a great job of moving request-scoped values around. What I meant to > ask about is how having contexts be embedded in request objects would help > in this process. Right now, my workflow and most everyone else's to my > understanding is to create a context from the request in the ServeHTTP > method and pass it around as the first argument to all my functions that > need request scoped values. How could this addition change how we use > contexts? For instance, are people going to start passing the request > object instead of the context object? > > > On Tuesday, July 12, 2016 at 6:28:12 AM UTC-7, Matt Silverlock wrote: >> >> Sure, and that's why gorilla/mux uses context.Context internally. >> >> gorilla/sessions (and mux) both existed well before context.Context did, >> and sessions can't be changed without breaking the public API. >> >> >> On Tuesday, July 12, 2016 at 4:20:59 AM UTC-7, parais...@gmail.com wrote: >>> >>> Don't you think it would be better to use context to hold session values >>> rather than using global variables like github.com/gorilla/sessions >>> does ? >>> >>> Le lundi 11 juillet 2016 00:43:05 UTC+2, Matt Silverlock a écrit : >>>> >>>> Use it to pass connection/request-scoped values: that is, values that >>>> could only exist once you have a request. authentication tokens, user >>>> details, connection IDs: things that can't be known/generated before the >>>> connection has been received. >>>> >>>> e.g. gorilla/mux (https://github.com/gorilla/mux) uses it to pass >>>> route-matching information back to the user (i.e. for /user/:name, the >>>> :name value). Don't use context to pass app-level dependencies, as it makes >>>> testing, reasoning and debugging hard. >>>> >>>> >>>> >>>> On Thursday, July 7, 2016 at 4:03:18 PM UTC-7, Tyler Compton wrote: >>>>> >>>>> I'm really excited to see context.Context become a first class citizen >>>>> in Go 1.7. After using context, it feels like a natural way to write Go >>>>> network code and it fits naturally in the standard library. I'm trying to >>>>> figure out how I can improve existing code with the new features that come >>>>> with it. >>>>> >>>>> In Go 1.7, requests now can contain a context, and the context can be >>>>> changed. This seems really cool, but I don't know what exactly I can do >>>>> that I can't do before, other than what the documentation specifically >>>>> outlines: "For outgoing client requests, the context controls >>>>> cancelation." >>>>> >>>>> Is there anything else we will be able to do that I should be looking >>>>> into? What are your plans? >>>>> >>>> -- > 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. > -- 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.
