Closed mjmar01 closed 2 years ago
Sounds reasonable and happy to add this, but until then as workarounds:
For the former case you could put it into an internal
subdirectory so its API was only exposed to a parent package.
For the latter case, in the past I've added converters.go
or etc files sitting along side generated files in the same package for that purpose.
But again, not an unreasonable ask.
@mjmar01 Feel free to check out the above PR and confirm it works for you
A few things. Most of them relate to sub types and slices of sub types.
-private-defintions
:)
type block struct {
a string
b string
} // Correct
type body struct { c Block } // Block not found
3. Point 2 also applies when pre allocating space for arrays using make(). So something like this might occur:
bbp.block = make([]Block, iohelp.ReadUint32Bytes(buf[at:])) // Block not found
4. The functions `maketype` and `maketypeFromBytes` are called like `MakeType...` which will say unknown function
5. Relating to 4 the new functions are not properly camelCase so `maketype` instead of `makeType`
6. Finally it might be good to run a go fmt over the output
Functionality it works tho. Does what I wanted it to
Did a more thorough look through with additional tests. I thought about adding a --format
option to the CLI, but it's not a great experience:
gofmt
always)-w $file
to rewrite a file in place, you can'tbebopc-go ... --format "gofmt"
is not an improvement over bebopc-go ...; gofmt -w ...
; the latter has the benefit that you can use whatever formatter accepting whatever arguments you want.
When compiling into an existing package it might be desirable to not export any functions or datatypes. This would be usefull in cases where the functions only get used inside the package or if I want to write my own wrapper functions to convert between types or similar.