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.
