I think that is why it is inconsistent and obtuse to me. The Log() method doesn’t need a pointer receiver. It works fine without it. It only needs a pointer receiver because when passed to a function declared as taking an interface a copy is made (and a reference to the copy held). This copy is implicit not explicit. This is a difficult model when working on large multi person projects - thus the “best practice” of using only pointer or value receivers I think. Suggesting that the linter flags code not adhering to this seems to have very little downside if any.
A quick search on the web (and the faq language) makes me think I am not alone in this opinion. I guess I still don’t see the downside to linter changes. As I said I reviewed a lot of the stdlib and I don’t see any obvious mixed receiver structs. They can be disabled on a per struct basis if needed. Anyway it was just my opinion based on my experiences. > On Jun 7, 2021, at 6:05 PM, Axel Wagner <axel.wagner...@googlemail.com> wrote: > > >> On Mon, Jun 7, 2021 at 11:42 PM Robert Engels <reng...@ix.netcom.com> wrote: > >> I don’t think that represents the problem fairly. In the non interface case >> I know I can’t accept a copy so I would declare the method as taking a >> pointer to the struct. > > How methods are declared should, in general, not be a matter of whether or > not they are assigned to an interface, but to whether or not they need a > pointer. Again: Your code is incorrect without interfaces. The problem > doesn't happen when you put that value into an interface - it happens when > you pass a copy of it and expect it to refer to the original. Interfaces are > just one way to create such a copy, but they do not matter for the > correctness of this code and for whether or not that method needs a pointer > receiver (it does). > > But again, to be clear: I'm not saying problems like this *never* happen and > I'm not even saying that interfaces may obscure it in some cases. Just that > a) the root cause here is that your method really needs to take a > pointer-receiver, interfaces or not and b) that it seems very much an > overstatement to me to call this "the most inconsistent and obtuse aspect of > the Go language". > >> With interfaces this is lost - as the interface is implicitly a pointer > > Well, it seems a bad idea to say that interfaces are implicitly pointers > then. That seems to indicate that Rob's original phrasing is indeed an > important clarification - the language behaves as if the value contained in > them is copied when the interface value is copied. > > It seems the confusion here is, that you assume it's not. And that interfaces > act as a pointers, when they don't. -- 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/F93E0A12-F3D2-4AAE-8D3E-091DF4A8AE60%40ix.netcom.com.
