In Go, slices can have methods too (indirectly). There can be so many use cases when slices can have methods. Have you ever come across a situation where you had a struct satisfying an interface but you had a slice of the same struct and hence you had to iterate over the slice and pass a single item eachtime to some function that accepted this interface? and imagine doing that multiple times in your code. Well, you don’t have to do that, there is a way for slices to have their own methods.
There is a tiny, important and a bit confusing thing to remember while dealing with Interfaces. I recently faced an issue while asserting a variable to a particular interface type. Even though I had defined all the methods to the struct type mentioned in an interface, I wasn’t able to assert it.
What are closures? From Wikipedia
A closure is a data structure storing a function together with an environment, a mapping associating each free variable of the function (variables that are used locally, but defined in an enclosing scope) with the value or storage location the name was bound to at the time the closure was created.
What does that mean?
In simple words, it means that a function can contain (or return) another function which is called closure.
Go doesn’t allow import cycles to occur. If there are any import cycles detected, it throws a compile time error. Generally import cycles are considered as a bad design. I recently came across such a situation when I wrote a test case to test my models, my config package that returned a db connection was dependent on model and the controller created a connection of type gorp.DbMap and passed it to each call in the model.