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?


Andrei

On Monday, 2 May 2016 at 12:52:42 UTC, Andrei Alexandrescu wrote:
>
> 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?

"Gflags, the commandline flags library used within Google..."

My perspective is those last three words are pretty important.  It's a clever idea that's great when you have a whole mountain of things that live and work together that were _designed_ to do so, but I don't think it's going to generalise well.  It's sort of like Bazel, which works in Google's colossal pillar of code, but doesn't tend to make a lot of sense for most other projects.

I could be wrong, though.  I've been using JCommander (http://jcommander.org/#Overview) at work this last week, and it hasn't been too bad.  It's a bit different though, because Java and the actual control over what classes you scan for options is still in your hands. (If I'm reading this right, Gflags isn't something you easily have fine control over-- you use it or you don't.)

-Wyatt

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.

On Mon, 2016-05-02 at 08:52 -0400, Andrei Alexandrescu via Digitalmars-
d wrote:
[…]
> to... thoughts?
>

Given the hassles with command line parsing for X applications (application and X) having any more places for options to be defined would, for me, be insanity.


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Monday, 2 May 2016 at 12:52:42 UTC, Andrei Alexandrescu wrote:
> I found this in https://peter.bourgon.org/go-best-practices-2016/:

> 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?
>
>
> Andrei

I think it would be good for a module to be able to define its options and then main expressly pulls them in. This is kind of already possible with option.passThrough, but that makes managing unknown flags harder and displaying help challenging. So I'd like to see getopt merge with another getopt.

On 2016-05-12 19:21, Nick Sabalausky wrote:

> 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.

I had to add several new flags when I worked with vibe.d, which I think should have been included from the start: the port to use, the address to bind, if worker threads should be used, number of threads to use.

-- 
/Jacob Carlborg

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

On 5/12/16 8:21 PM, Nick Sabalausky wrote:
> You may want to ask Sonke about his specific reasons and experiences
> with that design.

Yes please! -- Andrei

On Thu, 2016-05-12 at 18:25 +0000, Jesse Phillips via Digitalmars-d
wrote:
[…]
> unknown flags harder and displaying help challenging. So I'd like to see getopt merge with another getopt

getopt is a 1970s C solution to the problem of command line parsing. Most programming languages have moved on from getopt and created language-idiomatic solutions to the problem. Indeed there are other, better solution in C now as well.

D should have one (or more maybe) D idiomatic command line processing
libraries *NOT* called getopt.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 5/13/16 2:27 PM, Russel Winder via Digitalmars-d wrote:
> On Thu, 2016-05-12 at 18:25 +0000, Jesse Phillips via Digitalmars-d
> wrote:
> […]
>> unknown flags harder and displaying help challenging. So I'd like
>> to see getopt merge with another getopt
>
> getopt is a 1970s C solution to the problem of command line parsing.
> Most programming languages have moved on from getopt and created
> language-idiomatic solutions to the problem. Indeed there are other,
> better solution in C now as well.

What are those and how are they better? -- Andrei