add Getter methods for data structures

[willnorris]

as part of resolving #19, all data structures now use pointer field values. To ease the burden on developers to constantly perform nil checks, we should generate Get*() funcs on all our data structures, similar to what goprotobuf does. If a field is non-nil, return it. Otherwise, return the zero value for that type. So for example,

func (m *User) GetLogin() string {
    if m != nil && m.Login != nil {
        return *m.Login
    }
    return ""
}

Go provides good capabilities to read and manipulate go source code, so this can be completely generated. We might need to move all these types into a single data.go file, I'm not sure.

[willnorris]

Not yet starting work on this, but capturing some thoughts...

Go 1.4 added the go generate command which will make this a bit simpler (blog post: https://blog.golang.org/generate). The stringer command (https://golang.org/x/tools/cmd/stringer) should provide a nice starting point for writing a tool to generate accessor methods on our structs.

One question though is how to identify which structs should have generated accessors. go-github consists primarily of three types of structs:

• Services, used to break up the API surface into logical chunks
• GitHub resources
• Options, used to encapsulate optional arguments to various methods

We only want or need accessors on the GitHub resources. @bslatkin took the approach of using java-style comment annotations in bslatkin/joiner (blog post), which is kinda interesting, but noisier than I'd like:

// @joiner
type MyData struct{
    X float32
    Y float32
}

If we write the generator specific to go-github, we could do some really simple heuristics on type names. For example, skip anything that ends in "Service" or "Options". But an accessor generation tool like this does seem pretty generally useful, so I'd generally like the generator to be its own thing that maybe exposes a simple API that a go-github specific wrapper uses.

[parkr]

@willnorris Seems like a lot of work! I have been using Go's protobuf support recently to achieve this. Not only do you get the getters and setters for free, but you get a sweet new serialization format too! We have found it really nice at work. Maybe it's strange to define a .proto file for the primary purpose of generating setters and getters, but it'll do the job!

[willnorris]

@parkr Are you using protoc generated code in addition to hand-written structs, or instead of?

[willnorris]

Just to cut to the chase on why I ask... we tried to use protos for go-github but ran into lots of problems (see #19, notably #19 (comment) and #19 (comment)).

We could use protoc just to generate accessor methods but that creates two ongoing maintenance problems:

• github.proto would have to be kept in sync with the real go types
• the generated output from protoc would have to be edited to rip out all the stuff we don't want or need. That could be automated, but at that point you might as well generate it from the original go sources

Certainly, it's going to be some work to write the generation tool, but I don't think it will be too bad... stringer is 600 lines without tests. Plus, if designed well, it's something we'll only ever have to do once and can then be used by anyone else who similarly wants accessor methods for their pointer struct fields.

[willnorris]

though, it's also worth mentioning that I haven't looked at proto3 very closely and what its generated Go code looks like. There were some pretty big changes around the nullability of fields... basically, they take the Go approach and use the zero value for the type for unset fields. They handle nullability by having wrapper types that effectively do the same thing that we're doing by using pointers. I'm not sure what generated Go code looks like for those wrapper types, but I would imagine it's nothing too special, and would be even more annoying to work with than what we have today.

[parkr]

@parkr Are you using protoc generated code in addition to hand-written structs, or instead of?

The former. Your reasoning is sound – it sounds like you've been down this road. Just thought I'd throw that out there. 😄

[dmitshur]

@willnorris, what's the status of this issue (since you've self-assigned yourself to it)?

In #19 (comment), you said:

I'll open a new bug to look into generating convenience Get* methods similar to goprotobuf. In the meantime, users of the library will need to do their own nil checks.

But that was 2013, so I suspect this issue might be outdated and we probably don't actually want to do this anymore, do we?

[willnorris]

I never got to it, but I don't think it's outdated. Arguably, it's still something we should do.