Determine tag structure about options HOT 3 OPEN

Complete this issue before #2 , #7, #14.

from options.

Field-based options to consider:

• name
• ignore
• private

Only one of these particular options would be applicable at a time. If later options are feasible, they can be comma-separated. Name would be followed by an equals and the new func name, while ignore and private would be stand-alone toggles.

Example:

type FooOption struct {
  a string `options:"name=AssignA"` // Generates `AssignA`
  b int `options:"private"` // Generates `setB`
  c bool `options:"ignore"` // Does not generate a func
}

from options.

Consider the importance of this vs. allowing for configuration across the whole struct. Tags are only allowed on fields, and not the struct itself. This means that we cannot create struct-specific defaults. As a concrete example, we cannot set a default func prefix (i.e., "Assign" instead of "Set").

// FooOptions are all of the options for `Foo`
// +options:"prefix=Assign"
type FooOptions struct {
  // +options:"ignore"
  a string

  // +options:"private"
  B int

  c int
}

This would generate the follow:

func (fo *FooOptions) assignB(b int) options.OptionFunc {
   // etc.
}

func (fo *FooOptions) AssignB(c int) options.OptionFunc {
   // etc.
}

This appears to be a non-standard way of doing things in Go. But it's not unheard of. Correction: the idea is supported by Russ Cox (at least as of 2014):

Different programs process different special comments: the go command processes //go:generate, the compiler processes //go:noescape, third-party tools can process //other:thing, and so on. No program knows the full set of directives. All the more reason to make them ordinary comments.

from options.