Command line parsing

Nick Sabalausky via Digitalmars-d digitalmars-d at puremagic.com
Thu May 12 10:21:56 PDT 2016


On 05/02/2016 08:52 AM, 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?
>

Vibe.d uses a system (built on top of getopt, IIRC) that allows 
different modules to define and handle their own flags. It seems to be 
useful for framework-style libraries where there are certain common 
flags automatically provided and handled by the framework, and then 
individual app developers can add their own program-specific flags. You 
may want to ask Sonke about his specific reasons and experiences with 
that design.



More information about the Digitalmars-d mailing list