On 2016-05-02 14:52, Andrei Alexandrescu wrote:
I found this in https://peter.bourgon.org/go-best-practices-2016/:
"I said it in 2014 but I think it’s important enough to say again:
define and parse your flags in func main. Only func main has the right
to decide the flags that will be available to the user. If your library
code wants to parameterize its behavior, those parameters should be part
of type constructors. Moving configuration to package globals has the
illusion of convenience, but it’s a false economy: doing so breaks code
modularity, makes it more difficult for developers or future maintainers
to understand dependency relationships, and makes writing independent,
parallelizable tests much more difficult."
This is interesting because it's what std.getopt does but the opposite
of what GFLAGS (http://gflags.github.io/gflags/) does. GFLAGS allows any
module in a project to define flags. I was thinking of adding
GFLAGS-like capabilities to std.getopt but looks like there's no need
to... thoughts?
I can see it being useful for a tool like git which has sub
commands/actions to parse the global flags in the main function and
parse the sub command specific flags in the module handling the sub command.
I've also built a library that does some of the boilerplate to setup a
tool/application that parsers generic flags (like "help" and "version")
and allows to add application specific flags as well.
--
/Jacob Carlborg
