Closures vs structs with embedded functions (I call 'em pseudo-closures)

[xiio...@gmail.com]

I don't think I've seen this discussed once with respect to golang, and interested to see what others think, and more generally if anyone can give insight into pratfalls for the non closure method

Here's a simple program using the usual introduction to what closures can do https://play.golang.org/p/QN5bakBJ9J the second type allows a generic function to be supplied too.

I generally don't like closures because

1. they're 'hard' to look at eg this stuff - all those funcs

func MakeClosure2(i int, f func(*int)) func() {..}

2. the variable closed over is hidden, literally. I know some js people think that's a useful feature - not for me - just harder to debug

A like an alternative way to do for stuff like this - I first started doing this in javascript with objects .. in js the 'this' keyword can help a bit but its not essential - here's the first program rewritten to use structs https://play.golang.org/p/-v5C0bxiKB . The key difference is that the closed over variable is accessible as a field of the "closure struct" - (note the struct can also have multiple "closure functions" simply)

In short

closure way:

func MakeClosure(i int) func() {

return func() {

i++

fmt.Println(i)

}

}

created/called as 

c:=MakeClosure(10)

c()

struct way (pseudo-closure)

type Ps struct {

i int

}

func (x *Ps) Inc() {

x.i++

fmt.Println(x.i)

}

created/called as

ps:=Ps{i:1}

Ps.Inc()

observations:

The simplest example runs about 3x as fast for the struct 

The second example (supplied function) run about the same - but the closure version is a little faster 10%

I like how the signature of the function and the closed over variables are explicit in the struct..

Questions:

a.I'm wondering if there is something to go wrong with the struct method I'm using down the line I haven't forseen.

b.Is there another/better way to do it? Especially as regards clarity of intent in the program code..

c.Subtle (or not subtle) differences between the behaviours of the two ways I haven't already noted

d.I'm not expecting big differences in performance on real world examples - am I right?

[simon place]

aren't your "pseudo-closure"'s commonly know as "objects"?

[xiio...@gmail.com]

On Saturday, 13 August 2016 00:57:10 UTC+1, simon place wrote:

aren't your "pseudo-closure"'s commonly know as "objects"?

In languages that have "objects" (and not the structs I'm using here that serve the same function) the answer is yes.

Of course this is already known eg https://www.google.co.uk/search?q=objects%20vs%20closures 

I was interested in specifics technical to golang.

[Vincent Vetsch]

With the struct, the data can be modified outside of the inc() method, ie ps.i++ or ps.i--, ... it is much more flexible than a closure.  But if the data is critical, the closure is much more secure, only one function can change the data.  I hope this helps.