On Monday, 16 June 2014 at 21:21:47 UTC, Robert Schadek via
Digitalmars-d-announce wrote:
On 06/16/2014 11:11 PM, Dicebot via Digitalmars-d-announce
wrote:
On Monday, 16 June 2014 at 06:51:41 UTC, Jacob Carlborg wrote:
Pretty cool idea. Are you aware of that in D you can, at
compile
time, parse the doc string and generate a command line parser
for
that particular documentation.
I don't think it gives any advantage here :)
docopt looks cool, though my I'd prefer something that works
other way
around - automatically generates argument parsing code and help
messages from aggregate that represents configuration and/or
CLI API
(with help of few UDA).
+1 I could use reviews for this PR
https://github.com/D-Programming-Language/phobos/pull/2072
Sure, will have a look.
Though I don't see how what I propose can fit into Phobos as
std.getopt, it is something for an alternative module. The way I
see it, getopt will be more suitable for small simple CLI
implementations and that imaginary module - for programs with
huge amount of options and complicated nested commands.
Something like this:
@help("
Header used to describe this configuration option block
")
struct CLI
{
@descr("Some optional parameter")
Optional!int param1;
@descr("Mandatory parameter")
int param2;
struct Command
{
string nested_param;
void opCall(ref A outer)
{
// called after parsing relevant args into this
instance
}
}
Command command;
}
void main(string[] args)
{
Config config;
parseCLI!config(args);
// ./app --param2 42 command --nested_param yay
}