Function pointer vs interface for callback?

[sh...@tigera.io]

Hi,

I've been writing some code where I have nodes in a processing graph that need to notify other nodes when something changes.  I'm using callbacks (rather than channels, say) because I want everything to be synchronous.  It seems like I've got a choice between

type Foo struct {

    Callback func(baz Biff) Boff

}

and

type callback interface {

    func(baz Biff) Boff

}

type Foo struct {

    Callback callback

}

to represent the callback reference.  Is there a convention (or a good argument) for when I should pick one or the other?  Seems like a function pointer is more universal (I don't even need an object to be a receiver) but maybe an interface is more idiomatic?

Thanks,

-Shaun

[Ian Lance Taylor]

There are no hard and fast rules, but I think the func value is more
idiomatic. And if there aren't any other fields in Foo, I would write
it as

type Foo func(baz Biff) Boff

That said people do use interface values as well, as in go/parser.Visitor.

Ian

[Jesse McNelis]

On Wed, Oct 12, 2016 at 11:05 PM, <sh...@tigera.io> wrote:
> Seems like a function
> pointer is more universal (I don't even need an object to be a receiver) but
> maybe an interface is more idiomatic?

An interesting pattern from the http pkg is that a function type can
also implement an interface.
https://golang.org/pkg/net/http/#HandlerFunc

[Shaun Crampton]

Thanks for the tips.

[Chris Hines]

If you want to dig into this topic more. I gave a presentation on this topic at my local Go meetup earlier this year.

The slides from my talk are here: http://go-talks.appspot.com/github.com/ChrisHines/talks/non-orthogonal-choices-in-go/non-orthogonal-choices-in-go.slide#1

Some of the code examples will not run on the public go-talks app. The source material is at https://github.com/ChrisHines/talks/tree/master/non-orthogonal-choices-in-go.

If you just want my conclusion:

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

Based on these guidelines and the outline of your code you've provided, I agree with Ian that a function value is the best fit for your case.

Chris