object88 / options Goto Github PK

Starting with code...

package foo

type FooOptions struct {
  a string
}

func (fo *FooOptions) SetA(a string) {
  // etc.
}

The generator should not attempt to create a new SetA method.

Ensure that generated code is free from linting errors.

It should be noted that the generated code uses reflection, which is less performant than normal invocation. The generated code should be benchmarked and noted.

Go has a set of basic types (int, string, bool, etc). In addition, there are pointers (*int, *string, *bool`), arrays, maps, structs, pointers to structs, funcs, etc.. In the spirit of completeness, these should be explicitly tested.

Given a struct, generate options, compile, and run a test application to validate functionality

By default, option funcs are always generated. Add comment-based directive to allow for ignoring a field:

Example:

package foo

type FooOptions struct {
  //options:ignore
  a string

  b int
}

This should generate an OptionFunc for b, but not a.

The exact directive semantics are TBD, and will depend on the complete set of functionality to be baked into this tool.

By default, option funcs are public. Add comment-based directive to allow for generation of a private option func:

Example:

package foo

type FooOptions struct {
  //options:private
  a string
}

Generates:

func (fo *FooOptions) setA(a string) options.Option {
  // etc.
}

The exact directive semantics are TBD, and will depend on the complete set of functionality to be baked into this tool.

The generated code should include some message that indicates when the code was generated.

Create test to ensure proper functionality with go:generate

package foo

//go:generate options .:FooOptions

type FooOptions struct {
  a string
}

Can include information such as build time, github SHA, etc.

Reference:
https://blog.alexellis.io/inject-build-time-vars-golang/

package foo

type CommonOptions struct {
  debug bool
}

type FooOptions struct {
  CommonOptions
  a string
}

Also, consider nested struct from another package. Document limitations. For example, what is the expected behavior for an options struct that is composed with via two different paths:

package main

import (
	"fmt"
)

type A struct {
  a string
}

type B struct {
  A
  b string
}

type C struct {
  A
  c string
}

type D struct {
  B
  C
  d string
}

func main() {
  d := D{}
  d.B.a = "aaaaa"
  fmt.Printf("d: %#v\n", d)
}

Given the code...

type FooOptions struct {
  a string
}

func (fo *Foo) Apply() {}

Do not attempt to generate code. Doing so will result in the FooOptions struct having two implementations of an Apply method, which is illegal code.

Adjacently, consider whether the options.Optioner func Apply should have a different name.

Given code:

package foo

type FooOptions struct {
  //options:name AssignA
  a string
}

Generate an OptionFunc with a different name:

func (fo *FooOption) AssignA(a string) options.Option {
  // etc
}

The exact directive semantics are TBD, and will depend on the complete set of functionality to be baked into this tool.

The current implementation accepts a command-line argument to specify a path to a package and a target struct:

options ./example:FooStruct

An alternate might be to only supply the path, and allow an comment-based directive to define the target struct:

options ./example

With code:

package foo

//options:generate
type FooOptions struct {
  a string
}

Note that this goes contrary to the idea of using tags to instrument a struct for use with options. A tag cannot be applied to a struct, unfortunately. This idea may need to be abandoned.

Tags are useful ways to add extra information to a field in a struct, although not the struct itself, to facilitate operations on the field. See gophercon 2015 talk for interesting examples and idea.

In terms of options, we can leverage tags on fields to change how the generated option func is named, its privacy, or whether it should be ignored.

The exact semantics of the tag need to be determined, and validated so that they will pass go vet.

Further notes:
https://golang.org/ref/spec#Tag
https://github.com/golang/go/wiki/Well-known-struct-tags
https://medium.com/golangspec/tags-in-golang-3e5db0b8ef3e
https://stackoverflow.com/a/30889373/1301815