OK, I will try one more time. The following code is works fine from the developers perspective:
https://play.golang.org/p/gC1XsSLvovM <https://play.golang.org/p/gC1XsSLvovM> The developer says, oh cool, I see this great new 3P library that does background logging - I want to use that instead. Hey, I already implement the EventLogger interface, so no problem, I take out my manual logging code, and make a call to recordEvents(EventLogger). Hmm, my program isn’t logging properly any more. Oh, it says background logging - that likely means concurrency - so maybe I have a race condition, so I run it under —race. Hmmm, says it's fine and it still isn’t working. :( Eventually the developer figures out that the call to recordEvents() is making a copy, and so needs pointer receiver and to create a pointer based interface reference (and add the atomic calls). It’s not clear to me how the library author would document things to avoid this scenario. If you don’t see that the above is suboptimal and an AFI I am not sure what else I can say. That a person of your caliber writes code that differs from the recommendation in the FAQ (the mixing of receiver types) is a flag to me that one of the approaches is probably not correct. ‘go vet’ already has the ability to disable certain checks. Adding a check to ‘go vet’ to detect mixed receiver types (which the FAQ <https://golang.org/doc/faq#methods_on_values_or_pointers> says is not recommended) seems reasonable and will make life easier for many beginner Go programmers - and some seasoned ones as well :) The duplicitous and transparent nature of pointer/value receivers and interfaces is a source of confusion. I think being explicit would have been a better choice here but that horse has left the barn. > On Jun 8, 2021, at 1:54 AM, 'Axel Wagner' via golang-nuts > <golang-nuts@googlegroups.com> wrote: > > On Tue, Jun 8, 2021 at 6:36 AM Marvin Renich <m...@renich.org > <mailto:m...@renich.org>> wrote: > You say that test cases of Log work fine, but they are only fine in a > non-concurrent environment. The instant you test Log (without > interfaces) in a concurrent program it fails in an obvious manner. > > nit: I don't think concurrency has anything to do with it either. The failure > mode is making a copy and expecting the copy and the original to share > memory. If anything, concurrency (in a test) would make it more likely to get > hidden, by increasing the likelihood that a closure is used, which implicitly > shares a pointer: https://play.golang.org/p/Gwj9GScjQBJ > <https://play.golang.org/p/Gwj9GScjQBJ> > > Of course, concurrency then also makes the failure easy to see, as long as > you remember to run your tests with `-race`. > > FWIW I agree with Robert that it's relatively easy to write a test for this > that never copies the value (though even then, if you think about using > atomics you definitely should think about writing a concurrent test and > running it with `-race` enabled, which should show the problem). > I disagree with him, however, that interfaces make it more likely to run into > the problem when *using* the code. Any even remotely realistic usage of that > code is broken. Even if you failed to write tests which surface that breakage. > > > Interfaces, and their ability to potentially be satisfied by either a > non-pointer type or a pointer type, depending on the type, is not the > problem here. > > ...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 > <mailto:golang-nuts%2bunsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/20210608043609.gguu3t3hqbsziema%40basil.wdw > > <https://groups.google.com/d/msgid/golang-nuts/20210608043609.gguu3t3hqbszi...@basil.wdw>. > > -- > 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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGa5B99OO8oTxJOWFSuJPinPF3b1QJWEuqMD4ZPAiCi%3DQ%40mail.gmail.com > > <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGa5B99OO8oTxJOWFSuJPinPF3b1QJWEuqMD4ZPAiCi%3DQ%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- 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/A2CBA1A9-5342-4AAF-8393-A0DD96EC832A%40ix.netcom.com.
