You can also do it over just one function that takes in a variable that modifies behavior.
Imagine you have a closure with a function that takes in a string and a list and returns a list. Depending on implementation of the function, you could have the string be the operation you wish to perform. The method name, and the list be the parameters. The returned list is the output.
Getters could pass an empty list and return a list with one entry
Setters could pass a list with a value and return an empty list
And so on :)
Like this:
func NewClosure() func(string, ...float64) []float64 {
x := float64(0)
return func(method string, args ...float64) []float64 {
if method == "setX" && len(args) > 0 {
x = args[0]
return nil
} else if (method == "getX") {
return []float64 { x }
} else {
panic("invalid method")
}
}
}
a := NewClosure()
b := NewClosure()
a("setX", 50)
b("setX", 12)
fmt.Printf("a.X = %v, b.X = %v", a("getX")[0], b("getX")[0])
For this reason, I think of objects as not equivalent to closures, but rather ML-style functors. I think implementing objects as records with closures as fields is really just a poor man's parameterized module.
