Plans [spring 2014]
clipperhouse opened this issue · 5 comments
Just an update and request for feedback. Have a look at the typewriter branch for context.
gen will become a small shell and specific codegen libraries are included like “codecs” or “drivers”, mirroring the pattern in image and database/sql packages in the standard library.
My immediate milestone is to achieve parity with the existing gen under this new pattern. If users don’t see the change, great. Probably 90% there (on the branch).
It opens up the possibility of people making their own ‘gen’ with any code generator they want. Maybe Json? Trees? Fork it and change a few imports. Then the choice of ‘blessed’ typewriters not up to me! :)
But I have some even more-evil plans here – the typewriters would live as imports in the user’s codebase, not in the gen binary. That’ll be some voodoo.
Update: that latter bit of evil has been implemented on the typewriter branch thanks to @wfreeman. Experimental.
I feel perhaps a more ambitious target is called for. Gen is essentially a good idea - but quite limited whilst the generated code is fixed by its authors.
What's needed is a way for anyone to write their own a package (e.g. a set or list api) for a prototypical Go type, and then for Gen to generate any number of strongly-typed equivalents for other specified Go types. Gen would provide a small but useful suite of such re-usable code - especially the existing collection api.
I had a dabble with this idea one evening and it seemed likely that struct types and interface types may need separate handling on features like type assertions.
I built my own container template last night, not part of the gen project:
https://github.com/wfreeman/sortedcontainers
One thing I think needs working on is the ability to use gen with broken code (when the code is only broken because of things from gen that aren't generated)--while experimenting this bit me several times. Probably in practice this would be not a huge issue, since you'd check in your generated code, but it seems like maybe with the force flag we could just read lines from code to find the hints and do the generation.
@wfreeman Yes, dealing with broken code is definitely an issue. If the source is broken, gen can’t proceed.
The parent typewriter package does test validity of generated AST’s before committing to disk: https://github.com/clipperhouse/typewriter/blob/master/app.go#L91
Maybe one more step would be to send the generated code through the go.tools types.Check() as well?
Basically, do everything in our power to prevent invalid code from going to disk…emulate the build process.
@rickb777 Interesting...not quite sure what you envision. Maybe sketch it out in a Gist?
This has been implemented in v3. @wfreeman’s suggestion about better validation prior to writing to disk is still open.