proposal: add accessors to the expvar concrete types

[FiloSottile]

There is no good way to export expvar values. One can get as far as type-switching, but then the only method left is still String(), which has to be parsed by looking at how it's serialized in the expvar source.

As an example, I'd rather not have written this: https://github.com/thecodearchive/gitarchive/blob/4027007d21f759a1282c67ae44e6df099c208da4/metrics/influxdb.go#L31-L47

I propose adding the following accessor methods:

func (*Float) Value() float64
func (*Int) Value() int64
func (*String) Value() string // returns the unquoted version
func (Func) Value() interface{}

I considered calling them Int(), Float(), etc. but then String() would clash.

[ianlancetaylor]

I'm not really opposed to the idea, but it's not clear to me why you did write that code. Why not just export the variable as strings? What advantage do you get by converting them to specific types?

[FiloSottile]

I'm sending them to a TSDB, which needs to know that ints are ints to do all the fancyness and graphs. I used to just generate the JSON and parse it into a map[string]interface{} but then my int64 counters became float64 and lost precision (and type info).

[bradfitz]

I'm fine with this. Send a CL when Go 1.8 opens? Be sure to document the existing String.String method.

[adg]

@FiloSottile let's do this! 😄

[FiloSottile]

👍! CL incoming.

[gopherbot]

CL https://golang.org/cl/30917 mentions this issue.