Consider a function that saves streams of objects of different types to disk:
func Save(fill func(c chan BaseType), file string) {}
This function is used in the following way throughout the code:
// Here we've got different data structures data1, data2, ...
// that must be stored to disk
Save(
func(c chan BaseType) {
// SaveChildren1 generates objects of type Child1 based
// on the data1 data structure
SaveChildren1(c, data1)
},
filename1)
Save(
func(c chan BaseType) {
// SaveChildren2 generates objects of type Child2 based
// on the data2 data structure
SaveChildren2(c, data2)
},
filename2)
And so on. There are a lot of different child types and each requires it's own generator -- a function SaveChildren1, SaveChildren2 etc. These functions actually fill the channels with objects.
The question is how would you refactor these "binders" -- the functions that transform SaveChildren (a function of 2 args) into a function of 1 argument? Currently this code doesn't look like a well written go-style code.
The gob package seems like a good solution for your problem. There is a great article on the Go blog that explains how and why. A short excerpt:
The gob package was designed with a number of goals in mind.
First, and most obvious, it had to be very easy to use. First, because Go has reflection, there is no need for a separate interface definition language or "protocol compiler". The data structure itself is all the package should need to figure out how to encode and decode it. On the other hand, this approach means that gobs will never work as well with other languages, but that's OK: gobs are unashamedly Go-centric.
Efficiency is also important. Textual representations, exemplified by XML and JSON, are too slow to put at the center of an efficient communications network. A binary encoding is necessary.
Gob streams must be self-describing. Each gob stream, read from the beginning, contains sufficient information that the entire stream can be parsed by an agent that knows nothing a priori about its contents. This property means that you will always be able to decode a gob stream stored in a file, even long after you've forgotten what data it represents.
Further down the article is an example that shows how easy it is to use and how versatile it is.