INDEED HELPS A LOT. Thanks for pointing that out!. Thanks Scott!
The best greetings!! V El miércoles, 19 de diciembre de 2018, 20:52:18 (UTC-3), Scott Cotton escribió: > > > Hi, > > I think it's pretty clear with 3 rules: > > 1. Go is call by value, so structs are copied on calls while pointer to > structs are not. > > 2. Methods a.M(x) are just function calls f(a, x). > > 2. defer foo(bar) will evaluate the expression leading to a function, foo, > and the argument bar, in the context of the > defer statement. it will then apply the function to the previously > evaluated bar upon function exit (or after other defers > if there are any). > > Hope that helps > Scott > > On Wednesday, 19 December 2018 23:42:01 UTC+1, Victor Giordano wrote: >> >> Perhaps someone could explain to me (or enlight a litte bit why): why the >> defer is working like is working in the following cases, so, allow me to go >> straight to the examples: >> >> *https://play.golang.org/p/rLJ48Wur-n0* >> <https://play.golang.org/p/rLJ48Wur-n0> >> *My "**rought" **interpretation*: When the"defer" statement executes >> without any wrapper function, it grabs a copy of the struct (like an >> snapshot of it) to use when the execution of the defer's statements comes >> to place. Looks like that subsequent changes to the struct after the >> statement were the deferred function is evaluated are not reflected during >> deferred function execution. >> >> *https://play.golang.org/p/uGj3_FiMXTn* >> <https://play.golang.org/p/uGj3_FiMXTn> >> *My "rought" interpretation*: When the"defer" statement executes in a >> wrapper function, it doesn't grabs a copy in that right moment... look like >> that by the magic "laws of clousures" it mantains a "reference" (why not a >> copy as the first example?) to the struct so subsequent changes to the >> struct after the statement were the deferred function is evaluated (recall, >> in this case, a wrapper function) are actually reflected during deferred >> function execution. >> >> *https://play.golang.org/p/ahaO8s9dw5N >> <https://play.golang.org/p/ahaO8s9dw5N>* >> *My interpretation*: This is like the first case, but beign explicit >> about how the clousure is done. I wonder if this last example is the real >> explanation behind the first one. >> >> Bonus track case: *https://play.golang.org/p/YaQbQvF-8Sb* >> <https://play.golang.org/p/YaQbQvF-8Sb> >> *My interpretaion*: The closure takes a copy of the pointer, and a >> pointer is a pointer, so the real values are guaranteed to be reflected on >> the struct when the deferred function is executed. >> >> I would be very happy to hear any charity soul that wish to explain to me >> it. >> Thanks in advance. >> V >> > -- 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.
