Open ghost opened 9 years ago
Go's stringer tool does look simple.
\
and :\t
for formatting have been removed. Now the output is passed to (go/fomat).Source
instead. As a result the template has become a bit more cumbersome and ugly (as opposed to what I expected). But after template functions are introduced instead of a shitload of variables this must be improved. Maybe, we even won't need refactoring with fmt.Sprintf
.
Currently
text/template
is used for code generation. The way template looks like: https://github.com/colegion/goal/blob/master/tools/generate/handlers/handlers.go.template So, it's quite complex, we had to introduce\
to get rid of newlines and special meaning of:\t
sequence for formatting our code in a readable form.Now I lean toward an approach that is used by Go's stringer tool: https://github.com/golang/tools/blob/master/cmd/stringer/stringer.go#L560-L570. It's a set of consts and
fmt.Sprintf
. Looks simpler to me. Though, I'm not sure. Probably we should introduce some kind of package for code generation?Requirements are ease of use, ability to cover code by tests, probably type safety of the whole code generation stuff. Currently, template can be executed, rendered, and all but still output an incorrect go file. Is it possible to fix this?