args.d | a command line argument and config file parser

[H. S. Teoh via Digitalmars-d-announce]

On Tue, Aug 01, 2017 at 03:44:34PM +0000, Robert burner Schadek via Digitalmars-d-announce wrote:
> args.d is a command line argument and config file parser.
> 
> The basic idea of args.d is that that command line options and config
> file options are basically the same or should be.
> The configuration options are build from UDA annotated structs that
> can be nested.
[...]

Cool!  I had the same idea recently and implemented something similar
for one of my projects.  Great minds think alike. :-D

I think UDA-driven configuration parsing is ultimately the right
direction to go.  And by that I mean more than just command-line
parsing, but the parsing of configuration parameters in general,
including command-line options, configuration files, etc..  Usually a
lot of boilerplate is involved in constructing a parser, enumerating
options, then mapping that to configuration variables, adding helpful
descriptions, etc.. All of which are a maintenance burden on the
programmer, because any of these components can become out-of-sync with
each other: the parsing of parameters, the mapping of these parameters
to internal variables, and the help text.

With UDAs, it's possible to unify all three in one declaration, thereby
ensuring things will never go out-of-sync, and also greatly reduces the
amount of boilerplate the programmer has to type.

I didn't look too closely at args.d yet, but in my implementation, I
have UDAs for specifying alternate names for common configuration
parameters (e.g., "outfile=..." instead of "outputFilename=..."). This
allows more user-friendly option names, and also decouples it from
internal variable naming schemes.

There's also UDAs for optionally flattening a nested struct, so that
internally I can have separate structs for configuring each module, but
the main program combines all of them into a single flattened struct, so
that to the user all the options are top-level (can specify
"outfile=..." instead of "backend.outputFilename=..."). The user
shouldn't need to know how the program is organized internally, after
all, yet I can still properly encapsulate configuration parameters
relevant to only that module, thereby avoiding spaghetti dependencies of
modules on a single global configuration struct.


T

-- 
The easy way is the wrong way, and the hard way is the stupid way. Pick one.