Deploying first golang post

content/post/learning-go-pointer-receivers.md

@@ -1,7 +1,7 @@
 ---
-title: "Learning Go: Methods and Pointer Receivers"
+title: "Learning Go: Pointer Receivers"
 date: 2017-12-29T10:46:08-05:00
-draft: true
+draft: false
 tags: ["golang", "learning"]
 ---
 
@@ -22,24 +22,22 @@ that does a lot of cool things out of the box. Knowing how many problems I've ha
 (and missing compilers which catch some nasty bugs before the software starts), I want to learn Go and blog about cool things I find or cool
 things I do with it.
 
-## Methods in Golang?
+## Pointer Receivers?
 
-Yes, and this comes from old OOP concepts of message passing to objects. These methods are a neat way to be able to add functionality to your
+These are a neat way of providing methods for structures or builtin types that modify whatever the pointer points to.
-types you define in Go. If you are like me coming from OOP languages, methods are a very helpful construct.
 
 So we've got these people right? And people in this universe are very simple. All they have to identify them is their name, their astrological sign
 and their disposition.
 
 ```go
-type Person struct { name, sign, disposition String }
+type Person struct { name, sign, disposition string }
 ```
 
-Now a person's name may not change, not their sign, but what about their disposition? I'd say my average day is an emotional rollercoaster! Only kidding,
+Now a person's name may not change, nor their sign, but what about their disposition? I'd say my average day is an emotional rollercoaster! Only kidding,
 but we need a way to operate on the person's disposition, let's say based on weather.
 
 ```go
-// Actually a pointer receiver
+func (p *Person) AlterDisposition(weather string) {
-func (p *Person) AlterDisposition (weather string) {
     switch weather {
     case 'rainy':
         p.disposition = "sad"
@@ -51,7 +49,63 @@ func (p *Person) AlterDisposition (weather string) {
 }
 ```
 
-That's a funky syntax for this
+That's a funky syntax, but what that first parameter looking piece is right after `func` is a pointer receiver. You can think of this like being `self` for
+Ruby or Python. It refers to whatever type we are adding this method to, but the nice thing about a pointer receiver is that we are modifying the structure that
+`p *Person` points to vs. everything just being copies in local scope. Let's see this in action.
 
+```go
+package main
 
+import "fmt"
 
+type Person struct { name, sign, disposition string }
+
+func (p Person) GetDisposition() string {
+	return p.disposition;
+}
+
+func (p *Person) AlterDisposition (weather string) {
+    switch weather {
+    case "rainy":
+        p.disposition = "sad"
+    case "sunny":
+        p.disposition = "happy"
+    default:
+        p.disposition = "meh"
+    }
+}
+
+func main() {
+	var p Person = Person{ "Jake", "Sagittarius", "happy" }
+	fmt.Println(p.GetDisposition());
+	p.AlterDisposition("rainy")
+	fmt.Println(p.GetDisposition());
+}
+```
+
+The output of building and running this program is this:
+
+```
+happy
+sad
+```
+
+You can see that our little Jake person got upset that it started to rain, and the pointer receiver works as expected, altering our original
+`Person` object.
+
+A few notes about the pointer receivers.
+
+1. Receivers may only use named types
+
+    Receivers are the first part of the function signature directly after the func keyword
+
+    ```go
+    func (receiver Receiver) Method() {...}
+    ```
+
+    And the receiver MUST be a named type (structs, type definitions etc.). Also the receiver cannot be a named type that is itself a pointer.
+
+2. Style conventions are that if any pointer receiver is required, then all methods should have pointer receivers.
+
+    It is technically possible to have methods for both pointer receivers, and regular receivers, but you should only have pointer receivers if you need
+    even just one of them for a given type.