Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change the way code is generated #2

Open
ghost opened this issue Oct 2, 2015 · 2 comments
Open

Change the way code is generated #2

ghost opened this issue Oct 2, 2015 · 2 comments

Comments

@ghost
Copy link

ghost commented Oct 2, 2015

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?

@ghost ghost self-assigned this Oct 2, 2015
@ghost ghost added this to the v0.0.2 milestone Oct 2, 2015
@ghost ghost modified the milestones: Backlog, v0.0.2 Oct 16, 2015
@davidhunterxyz
Copy link
Member

Go's stringer tool does look simple.

@ghost
Copy link
Author

ghost commented Feb 10, 2016

\ 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant