On Mon, Oct 7, 2024 at 10:29 AM Ken Lee <ken.lee.kiany...@gmail.com> wrote: > > --- > There is a consideration to make, though: historically it has been considered > bad form in Go to give a type a mix of value and pointer receivers in methods > without a very specific reason for doing so. > --- > > Is this still the case now? As in 2024.
As a general guideline, yes. https://go.dev/wiki/CodeReviewComments#receiver-type Ian > On Sunday 13 January 2013 at 7:03:29 am UTC+8 Kevin Gillette wrote: >> >> Indeed. In addition to implicit dereferencing for value receivers, the >> reverse also works as well: anything that is addressable (including 'value' >> variables on the stack, or a field of element of anything that's >> addressable) will implicitly be addressed when a pointer-receiver method is >> called on them (though you must explicitly use the address operator when you >> need to pass value variables as pointers). >> >> There is a consideration to make, though: historically it has been >> considered bad form in Go to give a type a mix of value and pointer >> receivers in methods without a very specific reason for doing so. The >> typical justification is that a small struct in a getter method might as >> well have a value receiver even though the corresponding setter method uses >> a pointer receiver; this, however, can lead to confusion on the part of the >> app programmer if they start out using only the read-only methods upon what >> turns out to be a value-copy of the original (but hey, it compiled and seems >> to work, so it must be correct) -- when use of pointer-receiver methods >> don't seem to produce the documented changes in the original, it can be >> difficult to debug. >> >> >> On Saturday, January 12, 2013 3:17:16 PM UTC-7, Dave Collins wrote: >>> >>> On Saturday, January 12, 2013 3:52:35 PM UTC-6, Taric Mirza wrote: >>>> >>>> Thanks! Works like a charm and is helping cleaning up my code a ton. >>>> >>>> One other question, this is really more about coding style: >>>> >>>> In the case where you manipulate members of the struct, then using >>>> pointers as in your example is the way to go. >>>> >>>> But, you have a choice for functions that just read values from the >>>> struct instead of manipulating it. Is there a best practice coding >>>> style here, between dereferencing the struct and then using that, or >>>> dereferencing each member of the struct as you go? eg: >>>> >>>> // A: >>>> >>>> laser := worldobj.(*Laser) >>>> fmt.Printf("%0.4f,%0.4f", (*laser).x, (*laser).y) >>>> >>>> versus >>>> >>>> // B: >>>> >>>> laser := *(worldobj.(*Laser)) >>>> fmt.Printf("%0.4f,%0.4f", laser.x, laser.y) >>>> >>>> >>>> I'm kind of torn. I would imagine A) has slightly better >>>> performance, and doesn't require any code-rework if you later on need >>>> to manipulate the struct. >>>> >>>> On the other hand, B) is more readable since you don't have to look at >>>> pointers all over the place, just on one line. >>> >>> >>> Actually, you don't need to dereference at all. Go automatically handles >>> this for you. >>> >>> See this example: http://play.golang.org/p/ANaKaFSQLn >>> > -- > 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/03df7dce-5c48-44a3-bc3c-851ded2a1f08n%40googlegroups.com. -- 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/CAOyqgcX7v9Edk5beRH38tfJO18ZUXv-nOHsEPPCfMQy0hz%3DFdw%40mail.gmail.com.
