Issue with propagateInitFuncReturns flag (with multiple types) shows that current way of configuration isn't very flexible. I was going to add PR with new flag private (that generates constructors with package-private visibility, which I need) and faced the similar problem. Should this flag affect all types? - it may not be desirable, but looks like only way to do it currently (without introducing quite complex syntax like -private NameOfPrivateType1,NameOfPrivateType2 and so on). I realize that I can have multiple go:generate comments for each type, with separate sets of flags, by that way each constructor has to be in separate file - and I prefer to have constructors for all types from single file to be generated in single file, too.
I have proposition to introduce new way to configure type-specific options, by read it from comments associated with structs in AST (like many similar projects do). It may looks like this:
//go:generate go tool gonstructor -type Foo -type Bar -output cons.go
//gonstructor:flags -init initFunc -propagateInitFuncReturns -withGetter
type Foo struct {}
//gonstructor:flags -constructorTypes builder -setterPrefix With -returnValue
type Bar struct {}
We can leave global flags to treat them as default ones and maintain backward compatibility. With that syntax we can even use flag package to parse them, just like global ones.
Issue with
propagateInitFuncReturnsflag (with multiple types) shows that current way of configuration isn't very flexible. I was going to add PR with new flagprivate(that generates constructors with package-private visibility, which I need) and faced the similar problem. Should this flag affect all types? - it may not be desirable, but looks like only way to do it currently (without introducing quite complex syntax like-private NameOfPrivateType1,NameOfPrivateType2and so on). I realize that I can have multiplego:generatecomments for each type, with separate sets of flags, by that way each constructor has to be in separate file - and I prefer to have constructors for all types from single file to be generated in single file, too.I have proposition to introduce new way to configure type-specific options, by read it from comments associated with structs in AST (like many similar projects do). It may looks like this:
We can leave global flags to treat them as default ones and maintain backward compatibility. With that syntax we can even use
flagpackage to parse them, just like global ones.