* Robert Engels <reng...@ix.netcom.com> [231115 12:29]:
> What I’m suggesting is that imagine a dev changes that code and has
> version() access the request property…
Okay, that makes sense.
> This is why if you are sharing data in a concurrent way you need to be
> very careful of all usages.
Absolutely.
> The safest solution is to use immutable objects - of which the non
> pointer are.
Perhaps, but it is not appropriate in many cases.
> So saying - just use pointer receivers - woefully underestimates the
> work to do shared concurrent code correctly.
True.
I don't think there should be a default answer to "Which kind of
receiver should be used by default?" Each type deserves a deliberate
choice.
The thought process should include questions like:
Must the object be mutable?
Is the object large enough and will it be passed around enough that
copying it is likely to be a performance issue?
Will the type be assigned to an interface? How will its receiver type
affect its usage there?
When an object of a particular type is to be used concurrently, the
design of the type and its methods deserve careful thought, and no
"default answer" for any part of the design is going to do that thought
for you, whether it is receiver type, access control, or
synchronization.
...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/ZVURLIhbhoweVWSo%40basil.wdw.
