A quick trick: using Go struct
s to create namespaces
Suppose, not entirely hypothetically, that you have a bunch of expvar statistics variables in your program that you're registering yourself in order to create good names for them in the exposed JSON. Implemented normally, this probably leaves you with a bunch of global variables for various things that your program is tracking. Just like any other jumble of global variables, this is unaesthetic and it would be nice if we could do better.
Well, we can, due to Go's support for unnamed struct
types.
We can use this to basically create a namespace for a collection
of variables:
var events struct { connections, messages expvar.Int tlsconns, tlserrors expvar.Int }
In our code we can now refer to events.connections
and so on,
instead of having to have more awkward or more ambiguous names.
We aren't restricted to doing this at the global level, either.
You can fence off any set of names inside such a namespacing
struct
. One example is counters embedded into another structure:
type ipMap struct { sync.Mutex ips map[string]int stats struct { Size, Adds, Lookups, Dels int } }
For obvious reasons, this works best for variable types that don't need to be initialized; otherwise things get at least a least a little bit awkward with how you have to set up the initialization.
This is probably not to everyone's tastes and I don't know if it's
considered good Go practice. My personal view is that I would rather
fence off variable names with 'prefix.' than with say 'prefix_',
even at the cost of introducing such an artificial unnamed struct
,
but other people probably differ here. It does feel a bit like a
hack even to me, but maybe it's a legitimate one.
(For statistics counters specifically, this can also give you a convenient way of exposing them all.)
Out of curiosity I did a quick scan of the current development Go compiler and standard library and turned up a few things here and there that might be this pattern. There are variations and it's not all that common, so the most I'm going to say based on looking is that this doesn't seem like a completely outrageous and unsupported idea.
|
|