* Robert Engels <reng...@ix.netcom.com> [210608 18:30]: > I think the playground code I supplied is essentially a test case - > and it works in the absence of concurrency or other held references > (like putting it in a map).
But it is one simple test case, not an appropriate set of tests. Saying that code passes one test says very little about its correctness. It is often very easy to intentionally (or inadvertently) write a single test that passes, even though the code being tested is broken. > I guess the bottom line for me is that faq says do not mix receiver > types. There is either a valid reason for this or it should be > removed. I think it is the former as it makes more usage patterns > resilient to hard to track bugs. I think your MyEventRecorder is good anecdotal evidence that it is usually better to not mix receiver types. I don't think anyone is saying that the FAQ is wrong, just that it is not an absolute. I don't think Axel was suggesting that this should be removed, he was just giving an aside that he sometimes does not follow that advice, but he knows why he does and accepts the responsibility for any mistakes as a result. > I must be very dense but I still don’t see the rationale behind not > stating : use value receivers for immutable types and pointer > receivers otherwise. There may be some fringe cases where this doesn’t > hold - but if you can write the entire stdlib with this pattern it > seems fairly stable. The way I read it, that is the primary advice in the https://golang.org/doc/faq#methods_on_values_or_pointers section. It also gives some other considerations that may mitigate that advice. ...Marvin -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/YMAjJjDGsZfUpO7x%40basil.wdw.
