2

So if I have the following struct in Go:

type Person struct {
    name string
    age  int
}

Given that we don't know what consists of the Person struct, how could we find out programmatically? I've had a look around and it seems that reflection could be used to do this perhaps?

Even just getting the keys for the struct data would be a start, as type []string but ideally getting the types back also would be useful.

Harry Lawrence
  • 783
  • 1
  • 7
  • 17
  • Reflection is more likely to be the best way. Could you post some of the codw you have tried so far? – miltonb Apr 22 '14 at 10:48
  • I haven't actually got anything to post as of yet. I'm still trying to get my head around the various ways it can be done. Currently at a bit of a dead-end. – Harry Lawrence Apr 22 '14 at 10:52

1 Answers1

2

You can indeed use reflection to do this. You primarily want reflect.TypeOf, reflect.Type.Field, reflect.Type.NumField, and reflect.StructField

Code:

package main

import "fmt"
import "reflect"

type Person struct {
    name string
    age  int
}

func main() {
    typ := reflect.TypeOf(Person{})
    for i := 0; i < typ.NumField(); i++ {
        field := typ.Field(i)
        fmt.Println("Field name:", field.Name)
        fmt.Println("Field type:", field.Type)
        fmt.Println()
    }
}

Playground link

Some notes:

  • This works for both structs in your package and out of your package
  • If you need to actually change or read data, use reflect.ValueOf and pass it a pointer to the struct, followed by a call to Value.Elem()
  • You cannot set unexported fields in another package via reflect without a panic (well, okay, you can, but it involves unsafe and ain't pretty), but you can read them. This is not recommended.
  • Always consider if you actually need reflection before you use it. At the current time, you need to have Go source to successfully import the package, so if you just need to know field names it may be better to just poke around the source code. If you need to know at runtime, ask yourself why and if there's any possible way around it. Reflect is a landmine of bugs and quirky behavior.
Community
  • 1
  • 1
Linear
  • 21,074
  • 4
  • 59
  • 70
  • Works perfectly and seems to be an elegant solution! – Harry Lawrence Apr 22 '14 at 10:56
  • Excellent answer but I disagree with the last point, reflection is not needed most of the time, and it is slow, however it's neither buggy or nor quirky if used correctly. For example you need it for json/gob/xml/mgo.bson, etc. – OneOfOne Apr 22 '14 at 11:58
  • 1
    @OneOfOne I meant that in the sense that it's difficult to get right for a lot of people. It has a lot of behavior that makes total and complete sense if you know about it, but aren't immediately obvious (like passing pointers to ValueOf followed by calling Elem and stuff like that; also the way it deals with embedded types can be a bit wonky). I wasn't insinuating that reflect itself was buggy or quirky, just that if you don't know what you're doing you can get quirky and buggy behavior because you don't really get what it's doing. – Linear Apr 22 '14 at 12:19