Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[survey] Why HandlerFunc use value receiver instead of pointer #30

Open
at15 opened this issue Dec 19, 2017 · 0 comments
Open

[survey] Why HandlerFunc use value receiver instead of pointer #30

at15 opened this issue Dec 19, 2017 · 0 comments

Comments

@at15
Copy link
Member

at15 commented Dec 19, 2017

Arise from #26

When looking at apex/log's code (which use a net/http like handler style instead of logrus like formatter writer style), found the handy util type HandlerFunc func... which also appears in net/http

https://golang.org/src/net/http/server.go#L1914

type Handler interface {
  	ServeHTTP(ResponseWriter, *Request)
 }

// The HandlerFunc type is an adapter to allow the use of
// ordinary functions as HTTP handlers. If f is a function
// with the appropriate signature, HandlerFunc(f) is a
// Handler that calls f.
type HandlerFunc func(ResponseWriter, *Request)

// ServeHTTP calls f(w, r).
func (f HandlerFunc) ServeHTTP(w ResponseWriter, r *Request) {
    f(w, r)
}

The question is, why use func (f HandlerFunc) instead of func (f *HandlerFunc)

@at15 at15 self-assigned this Dec 19, 2017
at15 added a commit that referenced this issue Dec 22, 2017
- it use lock in handler implementations, for logging to stdout/err, I
think the reason the lock is needed is they call fmt.Fprintf
multiple times (for the message and fields) for a single log entry
- the overall process is entry.Debug -> Logger.log ->
Handler.HandleLog(*Entry) -> write to ouput (i.e.
fmt.Fprintf(io.Writer))
- it's good they didn't put Output inside logger, als othe HandlerFunc
part like `net/http`, though I still didn't know why it's using value
instead of pointer receiver #30
@at15 at15 added the area/go label Dec 28, 2017
@at15 at15 added this to the future milestone Feb 3, 2018
@at15 at15 modified the milestones: future, 0.0.8 Nov 25, 2018
@at15 at15 removed this from the 0.0.8 milestone Dec 9, 2018
at15 added a commit to dyweb/go.ice that referenced this issue Dec 30, 2018
- change test in makefile to only test new packages
- add ErrorHandlerFunc like net/http dyweb/gommon#30
- won't even realize that without adding unit test
@at15 at15 added this to the 0.0.10 milestone Dec 31, 2018
@at15 at15 modified the milestones: 0.0.10, future Apr 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant