== A quick trick: using Go _struct_s to create namespaces

Suppose, not entirely hypothetically, that you have a bunch of
[[expvar statistics variables https://golang.org/pkg/expvar/]] in
your program that you're [[registering yourself GoExpvarNotes]] 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:

.pn prewrap on

>  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 GoExpvarNotes]].)

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.