Re: [go-nuts] Understanding method pointers

Thanks for this explanation, it does make sense (in particular you unsafe example showing that they are different pointers) technically. It thus confirms that I am using method pointers in a "supported" by passing them around (in an interface) and expecting them to operate on their original st

Re: [go-nuts] Understanding method pointers

Sorry about the unclear code, that was just a consequence of simplifying down from the actual use-case, however, to me it seems not to be the same thing. In your example you have one struct and capture a method on that same struct twice, refering to the same - that makes sense. However, in my

Re: [go-nuts] Understanding method pointers

No, the question is actually, why methods bound to *different* pointers, still print the same: https://play.golang.org/p/o2lgZBBYx- The same can be observed for closures (unsurprisingly): https://play.golang.org/p/B6QKQWiraL I don't yet have a conclusive, detailed answer (I tried diving into the c

Re: [go-nuts] Understanding method pointers

I confess I find the code a bit convoluted and hard to follow - but doesn’t it just boil down to method values bound to the same pointer, thus acting on the same struct value (state)? https://play.golang.org/p/VVdSyaYp5x //jb On 9 Dec 2017, at 09:23, vik

Re: [go-nuts] Understanding method pointers

Apologies, I didn't really read the code you posted, so didn't understand the core of your question. Which is an excellent one. I have no idea. I will try to find out, but for now I'm stumped myself :) On Sat, Dec 9, 2017 at 11:12 AM, wrote: > Hi, > > Thanks for the tips, no, I have checked so t

Re: [go-nuts] Understanding method pointers

Hi, Thanks for the tips, no, I have checked so that all the methods are on pointers so thats not it unfortunately. I do now fully undertand you explanation for why I see the same adress being printed for both actions[1] and actions[2] though? In the playground example they are being called as

Re: [go-nuts] Understanding method pointers

Is it possible that some of your methods have a value-receiver? In that case, they wouldn't be able to mutate any state; *in* the method they'd have different addresses (as the methods act on a copy), but the variables that you call the method on would have the same address. It is hard to answer t

[go-nuts] Understanding method pointers

Hi, I have a problem that I have tried to reduce to a minimal re-producible example, I have not fully managed but it does show some to me strange behavior: https://play.golang.org/p/ZCyumUPBos I have a similar set up in a much larger set-up where I seem to see (no errors reported by race