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, <viktor.oge...@gmail.com> wrote: > 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 actions[1](c) and actions[2](c), so there > is no "additional" information being provided in the call, thus how can > they operate differently if it is the same thing that is being called > (since they have the same adr)? > > I understand that it's a challanging question without code exhibiting the > problem, will keep working on trying to reduce it. > > Thanks > > *from my phone* > > On Saturday, December 9, 2017 at 10:57:44 AM UTC+1, Axel Wagner wrote: >> >> 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 these questions, however, without any actual code >> showing the actual behavior that confuses you; we have to guess both about >> the behavior and the implementation, which is hard :) >> >> On Sat, Dec 9, 2017 at 9:23 AM, <viktor...@gmail.com> wrote: >> >>> 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-detector) that sometimes inside a "actionWithState" >>> the state is not remembered correctly/shared with other instances of >>> "actionState"s. In this playground example however it always seems to >>> behave as intended with each actionState's action method using its own >>> state. In the example above however (I see the same thing) both actions >>> *have >>> the same address* when printed, how can that be that they behave >>> differently if they point to the same data? >>> >>> >>> I.e. I have two questions where I would appreciate tips since I cannot >>> seem to wrap my head around it: >>> >>> 1. How can (in this code) actions[1] and actions[2] contain the same >>> pointers (as seen by fmt.Print) yet behave differently when called as >>> functions? >>> >>> 2. Although the behavior of the example above is what I expected (apart >>> from it printing the same pointer value), is there any circumstance under >>> which they would start to "share state" which I have not thought of that >>> could lead to the problem I am seeing in my larger code-base that you could >>> think of? >>> >>> >>> Any thoughts appreciated :-) >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to golang-nuts...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
