== Some things for enumerated constants in Go

The standard way to do C style _enum_s in [[Go http://golang.org/]]
is with [[_iota_ http://golang.org/ref/spec#Iota]] and a typed set
of constants. This looks like this:

.pn prewrap on
>  type SmtpCmd int
>  
>  const (
>      EHLO SmtpCmd = iota
>      MAILFROM
>      RCPTTO
>      ....
>  )

This set of constants is perfectly fine in one sense, but it has a
non-obvious drawback (at least for someone coming from a Python
world): you can't tell an uninitialized instance of _SmtpCmd_ from
an _EHLO_ value. Like all Go types, _SmtpCmd_ has a zero value and
since it's ultimately an integer the zero value is, well, 0. _iota_
starts numbering from 0 so _EHLO_ is also 0. Having your zero value
overlap with a valid value that you can see normally has the
possibility of hiding errors like uninitialized fields or unset
return values. Instead of being glaringly obvious it will just look
like your code is somehow incorrectly determining that you have an
_EHLO_.

The simple fix for this is to introduce a dummy first value:

>  const (
>      unsetCmd SmtpCmd = iota
>      EHLO
>      ....
>  )

(We make _unsetCmd_ start with a lower case letter so that it won't
be visible from outside the package. This may or may not be a good
idea depending on whether outside people generate instances of
_SmtpCmd_ or just look at them.)

The other thing you can do in Go with a typed set of constants is
to pretty-print them for the purposes of the _%v_ formatting operator.
All this takes is a _String()_ method function defined for your
type. Doing a minimal version that annotates the string value with
type information is simple but perhaps not completely useful:

>  func (v SmtpCmd) String() string {
>      return fmt.Sprintf("<SmtpCmd %d>", v)
>  }

More sophisticated versions are possible if you have either a source
of number to name mapping information or just build one yourself.
You probably don't need it to be strikingly efficient because you
probably won't be using _%v_ on your enumerated types very often.

(One thing you can do in even a simple version is specifically
annotate _unsetCmd_ and perhaps anything that's out of range for
your actual defined constants.)

=== Sidebar: A potential trick with _String()_ methods

In many cases being able to use _%v_ on your package's values is
most useful when debugging test failures. In addition, printing
useful information about them may involve crusty code that you
don't really like sitting around in the main package source.

As far as I can tell, you can actually put the _String()_ method
definitions in your ((*_test.go)) files and have them work. The
((*_test.go)) packages are an internal part of your package when
built for tests, but I believe that stuff defined in them is not
part of your package's exported functionality and the crufty and
internals specific pretty-printing code can live with the rest of
your testing code.

(Of course this may cause a certain amount of confusion someday,
when your package internal tests print out nice looking and informative
_%v_ values for things while in your outside code they just gets
eg basic numbers. This is your call to make. I honestly don't know
which side I come down on right now, although I get a half-pass
because I'm not writing a package I expect anyone else to ever use.)