Golang passing function as argument - go

Question

My question is related to an example from this link Effective Go. Why do they pass the function sum() as an argument vs calling it directly ? Below is the sample code from the link. The handle() function invokes sum() as req.f(req.args). What are the advantages of doing this way vs invoking it as sum(args) ?
type Request struct {
args []int
f func([]int) int
resultChan chan int
}
func sum(a []int) (s int) {
for _, v := range a {
s += v
}
return
}
request := &Request{[]int{3, 4, 5}, sum, make(chan int)}
// Send request
clientRequests <- request
// Wait for response.
fmt.Printf("answer: %d\n", <-request.resultChan)
func handle(queue chan *Request) {
for req := range queue {
req.resultChan <- req.f(req.args)
/**** how about calling the same function this way ***/
req.resultChan <- sum(args)
/***************************/
}
}

Answer 1

With only a single example of a Request this is a valid observation and question. However, if you limit yourself to only that one example of a Request to sum a fixed set of integers then you might also ask: why not simply do the arithmetic yourself and declare a constant?
i.e. all of this code is unnecessary, just write: fmt.Print("Answer: 12\n")
:)
So, assuming that all of this code serves some useful purpose, let's examine what those purposes might be...
The Use of Channels
A requests and results are passed via channels. Completely unnecessary in this case as the code is entirely synchronous, but in a more complex scenario where fulfilling a request involves some I/O, then channels help improve the efficiency of the code.
The example illustrates the pattern of sending a request over a channel, providing a per request result channel and receiving the result over the request specific result channel.
Request Fields (arguments/parameters)
By providing a Request struct that accepts a slice of ints, requests can be submitted to operate on an arbitrary number of arbitrary int values. There may be 0 or more ints that we want to process in a given request.
The example shows just one scenario involving the ints 3, 4, and 5.
The Func Reference
By providing a func reference in the Request, the specific processing performed by the request is decoupled from the asynchronous channel invocation used to make the request and return the result. This avoids having to recreate different handlers for different types of requests that operate over arbitrary slices of integers and return an int value.
The example illustrates using the asynchronous Request mechanism to sum() the slice of ints. But another request might involve a different function, e.g. mult(), which might multiply all the ints or mode()/median() to return the mode or median average
(a mean() request is not possible - at least not accurately - since that would need to return a float, which this particular Request type does not support via its channel int result channel).
Why Not Just Call sum() in the handle() func?
What the example illustrates here is "Inversion of Control" or "Don't Call Me, I'll Call You".
i.e. rather than embed the logic needed to fulfil each request in the function that handles the request, each request carries the required logic with it to be called by the handler. The handler is then only responsible for co-ordinating over the channels and calling the request logic at the appropriate point.
You don't have to do this and it may not be appropriate in all cases. Indeed, you could eliminate the sum() func entirely and implement the summing functionality directly in the handle func, if the handle func was only ever required to sum integers in a request (though there is still an argument for decomposing the sum functionality into a separate func to aid unit testing).
But if you did want to perform different asynchronous operations over slices of ints, e.g. multiplication or calculate averages using the same asynchronous pattern, you would need:
additional channels, one for each different type of request
additional handler funcs, one for each different type of request
additional goroutines to run the handler funcs
You wouldn't necessarily need different Request types themselves, since these would be the same and reduced to simply a slice of ints as "input" and the channel int for output. But it might be argued that they should still be separated into separate, different but identical types in order to separate the concerns (so you can change one request type without inadvertently affecting or even breaking the others).
A Different Example
The example falls a little short in not demonstrating the use of a second function operating over a slice of ints, to illustrate the flexibility of the implementation.
A more complete example might be:
package main
import "fmt"
type Request struct {
args []int
f func([]int) int
resultChan chan int
}
func handle(queue chan *Request) {
for req := range queue {
req.resultChan <- req.f(req.args)
}
}
func mult(a []int) (s int) {
if len(a) == 0 {
return 0
}
s = a[0]
for i, v := range a {
if i == 0 {
continue
}
s *= v
}
return
}
func sum(a []int) (s int) {
for _, v := range a {
s += v
}
return
}
func main() {
// Setup our request handler
requests := make(chan *Request)
go handle(requests)
// Setup some requests
ints := []int{3, 4, 5}
rqsum := &Request{ints, sum, make(chan int)}
rqprod := &Request{ints, mult, make(chan int)}
// Send sum request, wait for and print result
requests <- rqsum
fmt.Printf("sum: %d\n", <-rqsum.resultChan)
// Send product request, wait for and print result
requests <- rqprod
fmt.Printf("product: %d\n", <-rqprod.resultChan)
}
Please note that this does not necessarily illustrate good channel patterns or practices, only serving to demonstrate the inversion of control that function references provide!