Question about web.C documentation about goji HOT 4 CLOSED

I also have a somewhat related question about best practices for writing getters/setters on variables in web.C.Env. I am curious why the stock middleware getters such as https://github.com/zenazn/goji/blob/master/web/middleware/request_id.go#L76 accept web.C instead of *web.C.

All my setters/getters are of the form:

func SetX(c *web.C, val string) {
  c.Env["X"] = val
}

func GetX(c *web.C) string {
  return c.Env["X"].(string)
}

I thought this would be preferable to avoid copying the context when calling the getter. Am I making a mistake or missing something?

from goji.

An example of an invalid middleware:

func(c *web.C, h http.Handler) http.Handler {
        // This is wrong! Don't do this! (in practice, it will just be nil)
        urlParams := c.URLParams
        fn := func(w http.ResponseWriter, r *http.Request) {
                w.Write([]byte(urlParams["name"]))
        }
        return http.HandlerFunc(fn)
}

from goji.

Stock middleware getters take a web.C instead of a *web.C because HTTP handlers take a web.C (only middleware gets a pointer type, not the end handler).

In practice, so long as c.Env or c.URLParams is set, passing a web.C is sufficient: neither your getter nor your setter needs to accept a pointer type unless it is modifying the c.Env or c.URLParams maps themselves (by which I mean running c.URLParams = make(map[string]string]) or similar).

This also isn't meaningfully less efficient (web.C is two pointers wide, and the getter/setter call will probably be inlined anyways) but it means that a user of the library is not able to write a very large class of subtle bugs (e.g., since context allocations are reused for efficiency, if we passed a pointer it's possible for one request to squirrel away the *web.C and scribble on an unrelated request's context at some later time). I think it's worth giving up quite a bit of efficiency to make bugs harder to write, and the fact that we can get safety here without giving up ~any efficiency makes it an obvious win.

(To be clear, a middleware author could do something nasty here, and I made the opposite choice on the efficiency/safety tradeoff for middleware. However, I'm assuming that middleware authors know more about Goji than handler writers, and are more likely to carefully read documentation as well. This might turn out to be a lie.)

from goji.

Thank you, this is a very clear and helpful response. I'll go ahead and close the issue now and hopefully if somebody has a similar question they'll find this answer.

from goji.