www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - argument parsing into structure

reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
Sometimes a good API isn't the right answer. I like getopt as it 
is but I wanted a little different control. So I wrote up an 
article on my work around.

https://dev.to/jessekphillips/argument-parsing-into-structure-4p4n

I have another technique for sub commands I should write about 
too.
Jun 25 2019
parent reply JN <666total wp.pl> writes:
On Wednesday, 26 June 2019 at 05:38:32 UTC, Jesse Phillips wrote:

 Sometimes a good API isn't the right answer. I like getopt as 
 it is but I wanted a little different control. So I wrote up an 
 article on my work around.

 https://dev.to/jessekphillips/argument-parsing-into-structure-4p4n

 I have another technique for sub commands I should write about 
 too.


http://code.dlang.org/packages/argsd
Jun 26 2019
next sibling parent Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Wednesday, 26 June 2019 at 09:40:06 UTC, JN wrote:

 On Wednesday, 26 June 2019 at 05:38:32 UTC, Jesse Phillips 
 wrote:

 Sometimes a good API isn't the right answer. I like getopt as 
 it is but I wanted a little different control. So I wrote up 
 an article on my work around.

 https://dev.to/jessekphillips/argument-parsing-into-structure-4p4n

 I have another technique for sub commands I should write about 
 too.


 http://code.dlang.org/packages/argsd


http://code.dlang.org/packages/darg
Jun 26 2019
prev sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Wednesday, 26 June 2019 at 09:40:06 UTC, JN wrote:

 On Wednesday, 26 June 2019 at 05:38:32 UTC, Jesse Phillips 
 wrote:

 Sometimes a good API isn't the right answer. I like getopt as 
 it is but I wanted a little different control. So I wrote up 
 an article on my work around.

 https://dev.to/jessekphillips/argument-parsing-into-structure-4p4n

 I have another technique for sub commands I should write about 
 too.


 http://code.dlang.org/packages/argsd


I think we are several having written alternative getopt() 
systems.
I made one too last year, it allows to write tools very nicely.
Recent example for a device flasher:

---
module app;

import
     iz.options;

struct Handler
{
private:

public:

     /// Handle the "--help" command.
      Argument("--help", "prints the command line usage", 
ArgFlags(ArgFlag.allowShort))
     static void getHelp();

     /// Handle the "--info" command.
      Argument("--info", "prints the list of connected mods", 
ArgFlags(ArgFlag.allowShort))
     static void getInfo();
     /// Handle the "--readFlash" command.
      Argument("--readFlash", "read the firmware from the mod and 
save it to the specified file")
     static void readFlash(string fname);

     /// Handle the "--writeFlash" command.
      Argument("--writeFlash", "read the firmware from the 
specified file and send it to the mod")
     static void saveFlash(string fname);

     /// Handle the "--reset" command.
      Argument("--reset", "reset to factory state", 
ArgFlags(ArgFlag.allowShort))
     static void reset();
}

void main(string[] args)
{
     if (!handleArguments!(CanThrow, Handler)(args[1..$]) || 
args.length == 1)
         writeln(help!Handler);
}
---

https://github.com/Basile-z/iz/blob/master/import/iz/options.d#L379

Though I've detected several little flaws since it was written, 
but I don't care much  anymore about my own stuff these days...
Jun 26 2019
next sibling parent SealabJaster <sealabjaster gmail.com> writes:
On Wednesday, 26 June 2019 at 14:58:08 UTC, Basile B. wrote:

 I think we are several having written alternative getopt() 
 systems.
 ...


Here's another one to add to the list: 
https://code.dlang.org/packages/jcli

Similar to you I'm pretty sure there's glaring issues I haven't 
seen/fixed yet.

Since it'll be *a while* until I get documentation written, 
features written, and bugs fixed, the points of interests (or 
detest :) ) over other libraries would be:

* I'm trying to make all the building blocks reusable, so even if 
the user doesn't like my particular style, they'll still have the 
tools to easily make their own version.

* Building blocks include: A dodgy pull parser for arguments; A 
builder class for help text, currently with two built-in content 
providers (which means the user can also make their own); An 
ArgBinder helper, which can be used to create user-defined 
argument binder without any boilerplate outside of simply making 
the binder; And while there's only a few right now, I'm wanting 
to add a bunch of utility functions similar to scriptlike.

The ArgBinder is probably the only fully interesting part tbh 
(more for how it's used, rather than how it's implemented), full 
documentation is in it's doc comment (binder.d).
Jun 26 2019
prev sibling parent reply Jesse Phillips <Jesse.k.phillips+D gmail.com> writes:
On Wednesday, 26 June 2019 at 14:58:08 UTC, Basile B. wrote:

 On Wednesday, 26 June 2019 at 09:40:06 UTC, JN wrote:

 On Wednesday, 26 June 2019 at 05:38:32 UTC, Jesse Phillips 
 wrote:

 Sometimes a good API isn't the right answer. I like getopt as 
 it is but I wanted a little different control. So I wrote up 
 an article on my work around.

 https://dev.to/jessekphillips/argument-parsing-into-structure-4p4n

 I have another technique for sub commands I should write 
 about too.


 http://code.dlang.org/packages/argsd


 I think we are several having written alternative getopt() 
 systems.
 I made one too last year, it allows to write tools very nicely.
 Recent example for a device flasher:


The thing is, I didn't write an alternative, mine utilizes getopt 
which was the point of the article. I could build out new 
functionality onto a standard API which didn't support it. It 
isn't as robust as it could be.
Jun 26 2019
parent Basile B. <b2.temp gmx.com> writes:
On Wednesday, 26 June 2019 at 23:35:59 UTC, Jesse Phillips wrote:

 On Wednesday, 26 June 2019 at 14:58:08 UTC, Basile B. wrote:

 On Wednesday, 26 June 2019 at 09:40:06 UTC, JN wrote:

 On Wednesday, 26 June 2019 at 05:38:32 UTC, Jesse Phillips 
 wrote:

 Sometimes a good API isn't the right answer. I like getopt 
 as it is but I wanted a little different control. So I wrote 
 up an article on my work around.

 https://dev.to/jessekphillips/argument-parsing-into-structure-4p4n

 I have another technique for sub commands I should write 
 about too.


 http://code.dlang.org/packages/argsd


 I think we are several having written alternative getopt() 
 systems.
 I made one too last year, it allows to write tools very nicely.
 Recent example for a device flasher:


 The thing is, I didn't write an alternative, mine utilizes 
 getopt which was the point of the article. I could build out 
 new functionality onto a standard API which didn't support it. 
 It isn't as robust as it could be.


Sorry budy, I didn't want to ruin your announce.
Hold on ;)
Jun 27 2019