www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Command line parsing

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
May 02 2016
next sibling parent Wyatt <wyatt.epp gmail.com> writes:
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
May 02 2016
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.
May 12 2016
next sibling parent Jacob Carlborg <doob me.com> writes:
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
May 12 2016
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
May 13 2016
prev sibling next sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 2016-05-02 at 08:52 -0400, Andrei Alexandrescu via Digitalmars-
d wrote:
[=E2=80=A6]
 to... thoughts?
=C2=A0
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. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
May 12 2016
prev sibling next sibling parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
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.
May 12 2016
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 2016-05-12 at 18:25 +0000, Jesse Phillips via Digitalmars-d
wrote:
[=E2=80=A6]
 unknown flags harder and displaying help challenging. So I'd like=C2=A0
 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. =C2=A0 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
May 13 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
May 13 2016
next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 2016-05-14 at 07:34 +0300, Andrei Alexandrescu via Digitalmars-
d wrote:
=C2=A0[=E2=80=A6]
 What are those and how are they better? -- Andrei
C: argp, GNOME CLP C++ Clara, gtkmm CLP Python: argparse Groovy: Commons CLI wrapper =E2=80=A6 the list is quite lengthy. A table of data declaring all the things. No messing round with control flow during the parse. Automated message construction. Use of properties and data structure for all the results. Basically an increased level of abstraction. Imperative =E2=86=92 Declarati= ve. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
May 14 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/14/16 10:44 AM, Russel Winder via Digitalmars-d wrote:
 On Sat, 2016-05-14 at 07:34 +0300, Andrei Alexandrescu via Digitalmars-
 d wrote:
   […]
 What are those and how are they better? -- Andrei
C: argp, GNOME CLP C++ Clara, gtkmm CLP Python: argparse Groovy: Commons CLI wrapper … the list is quite lengthy.
I showed a fellow programmer std.getopt. We were both on laptops. He wanted to show me how good Python's argparse is and how D should copy it. By the end of the chat it was obvious argparse was much more verbose and less pleasant to use than getopt. Like you have to create an object (?!?!) to parse the command line and many other lines of nonsense.
 A table of data declaring all the things. No messing round with control
 flow during the parse. Automated message construction. Use of
 properties and data structure for all the results.
Where is the control flow in bool frob, meh; getopt(args, "frob", "This is the frob", &frob, "meh", "That's the meh", &meh); ? Honest question.
 Basically an increased level of abstraction. Imperative → Declarative.
I'm not seeing the imperative here. Care for a concrete side-by-side comparison? Pick your cherries. Andrei
May 14 2016
next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 2016-05-14 at 16:17 +0300, Andrei Alexandrescu via Digitalmars-
d wrote:
[=E2=80=A6]

 I showed a fellow programmer std.getopt. We were both on laptops. He=C2=
=A0
 wanted to show me how good Python's argparse is and how D should
 copy=C2=A0
 it. By the end of the chat it was obvious argparse was much more
 verbose=C2=A0
 and less pleasant to use than getopt. Like you have to create an
 object=C2=A0
 (?!?!) to parse the command line and many other lines of nonsense.
"verbose", "less pleasant" and "nonsense" are hardly the right terms unless the intention is to try to convince us using advocacy research. D will have whatever option parsing the people prepared to put in the effort and have the permissions and rights to add to the codebase want. Of course the more "democratic" way forward is to remove command line parsing from the D distribution and have it in the Dub repository as a package. Then there can be many different ways of doing things and statistics of downloads can be used to decide which is preferred. =C2=A0 This reminds me that SCons (and indeed CMake) probably need ways for specifying dependencies and retrieving them from the Dub repository, so that the Dub program is not needed.=C2=A0
=20
 A table of data declaring all the things. No messing round with
 control
 flow during the parse. Automated message construction. Use of
 properties and data structure for all the results.
Where is the control flow in =20 bool frob, meh; getopt(args, =C2=A0=C2=A0=C2=A0"frob", "This is the frob", &frob, =C2=A0=C2=A0=C2=A0"meh", "That's the meh", &meh); =20 ? Honest question.
I thought we were talking the C library which advertises=C2=A0http://www.gn= u .org/software/libc/manual/html_node/Example-of-Getopt.html#Example-of- Getopt=C2=A0as the official example and exemplar of getopt use.
=20
 Basically an increased level of abstraction. Imperative =E2=86=92
 Declarative.
I'm not seeing the imperative here. Care for a concrete side-by-side=C2=
=A0
 comparison? Pick your cherries.
See above: looks like a stonking great while loop to me. However if your use of getopt is different from that above, I can see that this argument is taking place by two people observing two completely different things, and is therefore not a discussion or an argument, but a point for a reboot of the thread! --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
May 14 2016
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 14 May 2016 at 14:29:04 UTC, Russel Winder wrote:
 However if your use of getopt is different from that above, I 
 can see that this argument is taking place by two people 
 observing two completely different things, and is therefore not 
 a discussion or an argument, but a point for a reboot of the 
 thread!
Indeed, D's getopt is almost nothing like C's getopt aside from the name - it is a from-scratch implementation more inspired by Perl than by C. from the docs: "Credits This module and its documentation are inspired by Perl's Getopt::Long module. The syntax of D's getopt is simpler than its Perl counterpart because getopt infers the expected parameter types from the static types of the passed-in pointers."
May 14 2016
parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 2016-05-14 at 15:14 +0000, Adam D. Ruppe via Digitalmars-d
wrote:
=20
[=E2=80=A6]
 Indeed, D's getopt is almost nothing like C's getopt aside from=C2=A0
 the name - it is a from-scratch implementation more inspired by=C2=A0
 Perl than by C.
I claim then that Andrei misdirected me by asking about C command line parsing. Also having a name other than getopt for the D thing would avoid these sort of misunderstandings. Whoever wrote the D CLP chose a poor label for it in my view. I would still prefer a data-oriented rather than opinion-oriented discussion of Python argparse vs. D getopt if there is to be a compare and contract debate. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
May 14 2016
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/14/16 10:29 AM, Russel Winder via Digitalmars-d wrote:
 On Sat, 2016-05-14 at 16:17 +0300, Andrei Alexandrescu via Digitalmars-
 d wrote:
 […]

 I showed a fellow programmer std.getopt. We were both on laptops. He
 wanted to show me how good Python's argparse is and how D should
 copy
 it. By the end of the chat it was obvious argparse was much more
 verbose
 and less pleasant to use than getopt. Like you have to create an
 object
 (?!?!) to parse the command line and many other lines of nonsense.
"verbose", "less pleasant" and "nonsense" are hardly the right terms unless the intention is to try to convince us using advocacy research.
Now that I've read your "getopt is a 1970s C solution..." comment I realize this might be a simple misunderstanding related to the fact you've never looked at D's std.getopt. It has nothing to do with C's getopt. The closest ancestor is Perl's http://perldoc.perl.org/Getopt/Long.html, but in D it's a lot better because of strong typing. Pray please take a look and sorry for taking your confusion for a semantic grenade. -- Andrei
May 15 2016
parent zabruk70 <sorry noem.ail> writes:
On Sunday, 15 May 2016 at 18:20:54 UTC, Andrei Alexandrescu wrote:
 please take a look
can't get usage text when it very needed https://issues.dlang.org/show_bug.cgi?id=14525
May 16 2016
prev sibling parent Jon D <jond noreply.com> writes:
On Saturday, 14 May 2016 at 13:17:05 UTC, Andrei Alexandrescu 
wrote:
 I showed a fellow programmer std.getopt. We were both on 
 laptops. He wanted to show me how good Python's argparse is and 
 how D should copy it. By the end of the chat it was obvious 
 argparse was much more verbose and less pleasant to use than 
 getopt. Like you have to create an object (?!?!) to parse the 
 command line and many other lines of nonsense.
I've found D's getopt package to be pretty good. There are a number of small things that could make it quite a bit better. To me these generally appear more the result of limited usage rather than anything fundamentally wrong with the design. For example, error text produced when a run-time argument doesn't match the option spec is often not helpful to the user who entered the command, and I've found I need to take steps to address this. A package like Perl's Getopt::Long tends to a bit more mature in some of these details. --Jon
May 14 2016
prev sibling next sibling parent reply Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
On Saturday, 14 May 2016 at 04:34:06 UTC, Andrei Alexandrescu 
wrote:
 On 5/13/16 2:27 PM, Russel Winder via Digitalmars-d wrote:
 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
Since no one has mentioned Vladimir's funopt yet: https://blog.thecybershadow.net/2014/08/05/ae-utils-funopt/
May 14 2016
parent Jacob Carlborg <doob me.com> writes:
On 2016-05-14 12:31, Marc Schütz wrote:

 Since no one has mentioned Vladimir's funopt yet:
 https://blog.thecybershadow.net/2014/08/05/ae-utils-funopt/
Looks really interesting. -- /Jacob Carlborg
May 14 2016
prev sibling parent reply Jason White <54f9byee3t32 gmail.com> writes:
On Saturday, 14 May 2016 at 04:34:06 UTC, Andrei Alexandrescu 
wrote:
 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
I wrote what I think is an idiomatic-D command line argument parser: https://github.com/jasonwhite/darg You basically define a struct with your options as members. The help string is then created at compile time(!). I find this much cleaner than std.getopt and the usage/help is prettier.
May 14 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/14/16 4:40 PM, Jason White wrote:
 On Saturday, 14 May 2016 at 04:34:06 UTC, Andrei Alexandrescu wrote:
 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
I wrote what I think is an idiomatic-D command line argument parser: https://github.com/jasonwhite/darg You basically define a struct with your options as members. The help string is then created at compile time(!). I find this much cleaner than std.getopt and the usage/help is prettier.
This is a terrific use of properties and it's a bit of a bummer std.getopt predates them. Thanks for an inspirational package. We should integrate some of these ideas in std.getopt and beyond. One simple step up for your package would be to do away with the enclosing struct - it can stay optional, but there's no real need for it. Andrei
May 15 2016
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Sunday, 15 May 2016 at 18:26:21 UTC, Andrei Alexandrescu wrote:
 On 5/14/16 4:40 PM, Jason White wrote:
 On Saturday, 14 May 2016 at 04:34:06 UTC, Andrei Alexandrescu 
 wrote:
 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
I wrote what I think is an idiomatic-D command line argument parser: https://github.com/jasonwhite/darg You basically define a struct with your options as members. The help string is then created at compile time(!). I find this much cleaner than std.getopt and the usage/help is prettier.
This is a terrific use of properties and it's a bit of a bummer std.getopt predates them. Thanks for an inspirational package. We should integrate some of these ideas in std.getopt and beyond. One simple step up for your package would be to do away with the enclosing struct - it can stay optional, but there's no real need for it.
I'm not sure if you saw it, but funopt uses the same basic idea. When writing ae.utils.funopt, I debated for a bit whether I should use a struct or a function signature as the base for specifying the arguments and their documentation. In the end I went with a function, because it covered all the most important cases, was simpler to use, and closer follows the analogy of invoking a process with some arguments vs. calling a function with some arguments.
May 15 2016
parent reply Jacob Carlborg <doob me.com> writes:
On 2016-05-16 01:36, Vladimir Panteleev wrote:

 I'm not sure if you saw it, but funopt uses the same basic idea.

 When writing ae.utils.funopt, I debated for a bit whether I should use a
 struct or a function signature as the base for specifying the arguments
 and their documentation. In the end I went with a function, because it
 covered all the most important cases, was simpler to use, and closer
 follows the analogy of invoking a process with some arguments vs.
 calling a function with some arguments.
To me it looks like it can get a bit too verbose for a single function when having more than a couple of flags. -- /Jacob Carlborg
May 15 2016
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Monday, 16 May 2016 at 06:36:03 UTC, Jacob Carlborg wrote:
 On 2016-05-16 01:36, Vladimir Panteleev wrote:

 I'm not sure if you saw it, but funopt uses the same basic 
 idea.

 When writing ae.utils.funopt, I debated for a bit whether I 
 should use a
 struct or a function signature as the base for specifying the 
 arguments
 and their documentation. In the end I went with a function, 
 because it
 covered all the most important cases, was simpler to use, and 
 closer
 follows the analogy of invoking a process with some arguments 
 vs.
 calling a function with some arguments.
To me it looks like it can get a bit too verbose for a single function when having more than a couple of flags.
I'm not sure what you mean, but if you mean what I think you mean, then just write the parameter list with one parameter per line, and it's no different from a struct.
May 17 2016
parent Jacob Carlborg <doob me.com> writes:
On 2016-05-18 03:15, Vladimir Panteleev wrote:

 I'm not sure what you mean, but if you mean what I think you mean, then
 just write the parameter list with one parameter per line, and it's no
 different from a struct.
I always end up with a struct or class any way to store the arguments, regardless of the framework or language I use. -- /Jacob Carlborg
May 18 2016
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
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
May 12 2016
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
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?
LLVM uses a gflags like system. That way, any pass can add its own configuration flag and it all works. On the other hand, it makes it impossible to have the same pass with different config and is a pain in the ass if not used from C/C++ . If I can see some projects benefiting from a GFlags like approach, I don't think it should be promoted by the standard lib. It only works well if all the code is writen to cooperate in a sensible way. This is good if you have end to end control, but really bad in the general case.
May 15 2016
prev sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Monday, May 02, 2016 08:52:42 Andrei Alexandrescu via Digitalmars-d 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?
My only issues with std.getopt have been its default settings (in particular that bundling is not turned on by default when in *nix-land at least, bundling is the norm) and the fact that it's a bit hard to handle errors from it. When it throws, you tend to just know that something failed on not what or why, but some improvements have been made to it with regards to printing help and whatnot, and presumably, further improvements could be made. I've never personally felt the need to add options/flags separately from main, but I've also never dealt with a framework that handled main for me such that I wasn't in control of the code to handle the command-line arguments in the first place. And certainly, my initial reaction is that being able to inject additional command-line argument handling elsewhere in the program is a bad idea and that if there is a framework that handles main for you such that you aren't dealing with the command-line argument handling directly, then it should provide a way for you to hook into the command-line argument handling rather than just letting it be injected willy-nilly. GFLAGS just seems like a bad idea to me. It might make sense in some circumstances, but I'm inclined to think that such circumstances aren't normal enough or common enough to warrant being explicitly supported in the standard library. - Jonathan M Davis
May 17 2016