Information, examples, and tips about Pointers in Golang
Sean Kelly
@StabbyCutyou
I work for Tapjoy
I am a core mainter of:
Buffstreams : Streaming Protocol Buffers over TCP
http://github.com/StabbyCutyou/buffstreams
Moldova : Randomized templated data
http://github.com/StabbyCutyou/moldova
Chore : Tapjoys Job System in Ruby
http://github.com/Tapjoy/chore
What are they?
What benefits do they have?
When to use them?
When not to use them?
Some of this might bore you
I don't have any ground breaking revelations about Pointers
This talk is to introduce the basics in Go
However, since this is all anyone cares about anyways...
My opinion is to use Pointer receivers on your methods by default
Have a safe trip home!
Pointers are a lot like "regular" variables
You can use them like a variable to call methods or properties of a value
You can pass them to functions
They get garbage collected
But each one of these things is a little different
Structs are passed as values
Everyone gets their own copy of the value in memory
Pointers act as references*
Everyone shares a reference back to the same place in memory
Remember: If the value inside the Pointer isn't threadsafe, you need to protect it!
Golang uses a 3-color, Mark and Sweep GC. Once something cannot be "colored", it's considered out of scope
Normally, variables are collected once they fall out of scope
The memory addressed by a Pointer can be shared over many scopes
The memory addressed by a Pointer is only collected once it falls out of all scopes
Interesting Fact: Anything you can create with make, is automatically treated like a Pointer
... Even if you didn't use make to create it
Including everyones favorite question
Should I use a Pointer or a Value as a method receiver?
Pointers, in most cases
Typically, you want to be using Pointers where possible
Additionally, you want to watch out for "Accidental Copying" when not using Pointers
Never use an interface as Pointer. It's technically already one
Interfaces are actually 2 pieces of data working in tandem:
The first points to memory address holding the underlying type
The second points to the actual value in memory
So, you never want to do this: f := func(i *MyInterface){}
But, you can totally do this: f(&S{})
That's because both S and *S adhere to the definition of MyInterface
The most common mistake people make when serializing (ex: JSON)
If a field can be null, you must declare it as a Pointer type
Otherwise, Golang will fill missing data in with a value-based Zero Value
There are similar concerns at play in other Serializations as well (ex: SQL)
Technically, you can declare a type as Pointer of an existing type
Example: type PointS *S
Important note: With few exceptions, there is no type-aliasing in Golang. This is a brand new type
Should you declare types this way?
My opinion is probably not
It's less clear to the reader, and it's easy enough to use custom types as Pointers already
You can declare Pointers to Pointers
If you've shared a Pointer P to a particular value, and wish to change the memory address it points to, not the value inside the address...
You'd use a Pointer to a Pointer
This is because many concurrent users of the Pointer would have copies of it which still point to the original place in memory
This means passing around Pointers is actually copying the Pointer (but not the value it points to)
A Pointer itself is actually a kind of (and passed by) value! (Remember my asterisk from before?)
Therefore, passing around a Pointer to a Pointer lets you swap in different Pointers simply
This, like other shared state, is not thread safe
Pointers can be used mostly like regular variables
Go ahead and declare those method receivers on Pointer
You don't want to use Interfaces as Pointers, but using them with Pointers is fine
Serializing data? Remember your Pointers if fields can be null
Sharing References == Sharing State == Threadsafety Concerns
Pointers to Pointers are a little heady, but very important when needed
My wife really, really wanted me to add puns like these to my talk:
I'm going to give you some "pointers" tonight
Here are some "tips" to help you stay "sharp" with pointers
I hope I've made my "point"
"This talk was so great, it's inspired me to new heights!" ~ Georges Seurat
What's the Point?
Information, examples, and tips about Pointers in Golang
Sean Kelly
@StabbyCutyou
Dave Cheney : http://dave.cheney.net/2016/03/19/should-methods-be-declared-on-t-or-t
Steve Francia (sp13): http://spf13.com/post/go-pointers-vs-references