4 ms·
> particularly in Go where everyone crams everything into single-func interfaces which are almost exclusively far worse Depending on scope, I've grown to prefe
by throwaway073123 3y ago
> particularly in Go where everyone crams everything into single-func interfaces which are almost exclusively far worse
Depending on scope, I've grown to prefer the single func interface.
For a smaller scope use, say filepath.Walk, absolutely, pass in a closure, good stuff.
For larger stuff, like say a chain of http middleware and handlers, I think it can be very limiting.
you get a big benefit from using the interface over a function: the underlying type _can_ have more methods and implement.
this gives room to implement a parallel interface, for example, to collect all possible routes, or to trace what handlers a request would pass through.
I don't think there's a one-size-fits all approach, use whatever gives the effort:utility tradeoff you're looking for.
- Groxx 3y agoFunc references can have methods as well fwiw :) They just need to have a named type. But sure, if you want to build a multi-method thing (or upcast to detect optional methods), an interface is the natural choice - it's no longer a single func.
- throwaway073123 3y agoAbsolutely. If I see a one method interface, I generally assume that there's a ThingDoerFunc type that implements the interface. Likewise, (ThingDoerImplemetation{}).DoThing is a valid func reference Hence I say there's not really a one size fits all, there are a options for different circumstances.