---
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.
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.
