Hacker News Reader

Comment by 0xfaded | Hacker News Reader

One thing I don't like about these packages is the use of map[string] string to represent dynamic url parameters. The conversion into a useful type seems like something that could (and should?) be automatic.

Shameless plug: for my own use I wrote https://github.com/0xfaded/rhttp which is used with (not a thin layer over) net/http. There is a draftish blog post to go with this http://blog.0xfaded.com/.

As a side note, I use an unusal pattern of passing an empty struct as a function arguement for the sole purpose of being inspected using reflection. Undecided if this is good or bad. Thoughts?

View on HN

Nice package. I like the fact that it's limited in scope and actually does some work for you. There's a trick you're missing though - you require the user to pass in their expected params struct explicitly so you can reflect on its type, but you could just reflect on the handler function type itself.

Then a handler function could look like this:

    func Do(w http.ResponseWriter, r *http.Request, params *DoParams) {
         w.Write([]byte(params.Var))
    }

No need for any dynamic type coercion - it can all be checked up front when the handlers are registered. The down side is that the signature of Handle would become more opaque (its argument would just be an interface{}) and you'd probably want to lose the Handler type.

FWIW, passing an empty struct for the sole purpose of being inspected using reflection is not unusual (see for example gob.Register).

I'm aware of this, however there is a pretty serious downside: function decorators (currying, whatever you want to call it) become difficult if type information is encoded in the function signature. For example, I mark handlers for logged in users by:

  handle(..., User(F))

The prototype of F and User might be

  func F(w http.ResponseWriter, r *http.Request, s *Session, i interface{})
  func User(...type of F...) func (http.ResponeWriter, r *http.Request, i interface{})

User() would do some preprocessing on the request and produce a Session for F. The problem is that User accepts ...type of F...; although it could accept an interface (of a function) but doing everything by reflection becomes cumbersome.

This is one of the things I don't like about go but really you need a type system like haskell's to achieve what I want here.

You could create a dummy interface which all your DoParams-like types could implement:

    type Params interface { IsParams() }

Also, you can get away with passing a nil pointer for reflection rather than allocating a nil struct:

    fmt.Printf("nil pointer to DoParams: %T", (*DoParams)(nil))
    fmt.Printf("pointer to nil DoParams: %T", &DoParams{})

(Which isn't going to be a source of gc pressure in this instance, but still...)

Reply on news.ycombinator.com