[go-nuts] Re: Interface vs first-class function

With a nod to Chris's excellent presentation, this may be an example of Go breaking its own orthogonality rules for the sake of being more consistent (the rule of least surprise) There is a strong overlap between an interface with a single method and a function value, Tomás Senart spoke about t

[go-nuts] Re: Interface vs first-class function

A few other thoughts on this: 1 - Method values mean that you can get a function type that accesses state without closures over local variables: a := &myStruct{} // b is a SomethingDoer function b := a.DoSomething e.g. https://play.golang.org/p/SVY8rQ8WR_ 2 - Method values also mean that multi

Re: [go-nuts] Re: Interface vs first-class function

https://github.com/julienschmidt/httprouter https://github.com/pressly/chi and others actually use a function by default because it's the more common case. See https://github.com/pressly/chi/issues/94#issuecomment-254516724 On Mon, Nov 21, 2016 at 12:39 AM Tamás Gulácsi wrote: > I don't think

Re: [go-nuts] Re: Interface vs first-class function

I don't think so. A http.Handler usually has a ton of state, so a struct's method is handier than a closure. And take a look at http.HandlerFunc! -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving e

Re: [go-nuts] Re: Interface vs first-class function

In relation to this question, do you guys think it would have been better had http.Handler been a function, not an interface? On Sun, Nov 20, 2016 at 11:23 PM Henry wrote: > Thanks for the replies. In terms of future extensibility, is it safe to > say that interface is superior to first-class fu

[go-nuts] Re: Interface vs first-class function

Thanks for the replies. In terms of future extensibility, is it safe to say that interface is superior to first-class functions? -- 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, se

[go-nuts] Re: Interface vs first-class function

you'll need interfaces if you want your 'thing' to leave the programs context, to store/transmit it. -- 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

[go-nuts] Re: Interface vs first-class function

I tried to break down the thought process on this exact question earlier this year and gave a presentation at my local Go meetup. My slides are here: http://go-talks.appspot.com/github.com/ChrisHines/talks/non-orthogonal-choices-in-go/non-orthogonal-choices-in-go.slide

[go-nuts] Re: Interface vs first-class function

To be more concrete, taking your example, PerformWork cannot be easily customized according to the type of first class function that returns a func(Data). Actually it goes further, because that first class function can "only" return a func(Data) and not multiple functions. With an interface, it

[go-nuts] Re: Interface vs first-class function

You have less indirection with the interface. More ergonomic. An interface also allows to define a set of constraints whereas the first class function does not coerce you into having a defined set of function arguments. On Sunday, November 20, 2016 at 6:22:57 AM UTC+1, Henry wrote: > > Hi, > > I