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

[Dave Cheney]

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 this at last year's Gophercon, but as 
a function value cannot easily have two behaviours there is clearly a 
requirement for an interface with two or more methods (although SRP would tend 
to drive your design in the other direction, sometimes this is necessary) so an 
arbitrary restriction that an interface have more than one method would be 
surprising.

I think there is a strong parallel between this discussion and the occasional 
flair up of the "why does Go need new?" debate. The answer in both cases is 
while sometimes features appear to overlap in the simple case, they are 
actually independent. A small concession for consistency over orthogonality. 

Dave

-- 
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.

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

['Colin Stewart' via golang-nuts]

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 := {}
// b is a SomethingDoer function
b := a.DoSomething

e.g. https://play.golang.org/p/SVY8rQ8WR_

2 - Method values also mean that multiple methods can be provided that 
satisfy a function type but operate on the same data, something that 
requires creating new types to do with interfaces (though very do-able - 
see SortWrapper example in https://golang.org/pkg/sort/)

a := {}
// b and c are both SomethingDoer functions
b := a.DoSomethingAlphabetically
c := a.DoSomethingChronologically

3 - (In my view a minor point) - It's clearer at the call site as to which 
function is being called without an interface:

needsADoer (a.DoSomething) versus needsADoer (a)

I tend to use interfaces for things with multiple methods that need to work 
together and function types for single method abstractions.

-- 
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.

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

['Anmol Sethi' via golang-nuts]

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 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 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.

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

[Tamás Gulácsi]

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 emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

['Anmol Sethi' via golang-nuts]

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 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, 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.

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

[Henry]

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, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

['simon place' via golang-nuts]

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Chris Hines]

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
 


TL;DR

Informed choices for dynamic behavior

Use interface values when:

   - Well known interfaces already exist, e.g. io.Reader
   - More than one behavior required
   - Typically stateful
   - Implementations non-trivial
   

Use function values when:

   - Only one behavior
   - Typically stateless
   - In-line implementations typical
   
Hope it helps.

Chris

On Sunday, November 20, 2016 at 12:22:57 AM UTC-5, Henry wrote:
>
> Hi,
>
> I am wondering from best practice point of view whether it is better to 
> use interface or first-class function, especially considering that Go 
> encourages the use of small interfaces. Here is an example:
>
> type SomethingDoer interface{
>DoSomething(data Data)
> }
>
> func PerformWork(doer SomethingDoer){
>//...
> }
>
> Or 
>
> type SomethingDoer func(Data)
>
> func PerformWork(doer SomethingDoer){
>//...
> }
>
> Is there some sort of a guideline when to use one vs the other? They seem 
> like redundant features to me.
>
> Thanks
>
> Henry
>
>

-- 
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.

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

[atd...@gmail.com]

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's equivalent to being able to pass a first class 
function returning possibly multiple values of which at least one is of 
type func(Data).
More than that, we have ways to discover some of the other return values 
and adapt PerformWork execution accordingly.



On Sunday, November 20, 2016 at 1:25:11 PM UTC+1, atd...@gmail.com wrote:
>
> 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 am wondering from best practice point of view whether it is better to 
>> use interface or first-class function, especially considering that Go 
>> encourages the use of small interfaces. Here is an example:
>>
>> type SomethingDoer interface{
>>DoSomething(data Data)
>> }
>>
>> func PerformWork(doer SomethingDoer){
>>//...
>> }
>>
>> Or 
>>
>> type SomethingDoer func(Data)
>>
>> func PerformWork(doer SomethingDoer){
>>//...
>> }
>>
>> Is there some sort of a guideline when to use one vs the other? They seem 
>> like redundant features to me.
>>
>> Thanks
>>
>> Henry
>>
>>

-- 
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.

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

[atd...@gmail.com]

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 am wondering from best practice point of view whether it is better to 
> use interface or first-class function, especially considering that Go 
> encourages the use of small interfaces. Here is an example:
>
> type SomethingDoer interface{
>DoSomething(data Data)
> }
>
> func PerformWork(doer SomethingDoer){
>//...
> }
>
> Or 
>
> type SomethingDoer func(Data)
>
> func PerformWork(doer SomethingDoer){
>//...
> }
>
> Is there some sort of a guideline when to use one vs the other? They seem 
> like redundant features to me.
>
> Thanks
>
> Henry
>
>

-- 
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.