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