So in your example,

var t T = s

defines a new variable of an interface type, and implicitly *copies* the
contents of s.

so if what I wanted was a reference and not copy, I would do this:

var t T = &s

interesting... so structs really don't behave like objects in other
languages - your default (or in some languages your only) option is not to
pass them around by reference, but to treat them just the same as any other

I can think of a few cases where that would be a real advantage - for
natural value-types such as date, time, date/time-range or color models,
this is often a real pain in other languages where you have to design such
types either to be immutable objects where every method that modifies the
value has to return a new object.

But that also means you have to pay attention though, and take care to
avoid e.g. copying expensive structs, right?

I can also think of examples where copying would actually cause problems -
simplest example I can think of: if you accidentally made a copy of a
service object that has an internal counter, that was supposed to return
the next unique number in a sequence. If you have two copies, each copy
will continue counting independently from when it was copied.

In cases like those, would you need to hide the object behind an API
somehow, so it can't be copied? Or is there a better way to handle that?

On Fri, Dec 27, 2013 at 12:09 PM, chris dollin wrote:
On 27 December 2013 17:00, Rasmus Schultz wrote:

Conceptually: not structs -- any type.
right! got it, thanks :-)
not references -- copies.
copies? I don't understand - when would they get copied?
When you do an assignment / pass a parameter, "just like" the
usual way -- that is, if you assign a struct value to an interface
variable, then fiddle with the struct, that doesn't change what the
interface stores.




Chris "allusive" Dollin
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2022 Grokbase