[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [nmh-workers] Refactoring smatch

From: Ralph Corderoy
Subject: Re: [nmh-workers] Refactoring smatch
Date: Wed, 11 Sep 2019 13:38:36 +0100

Hi Ken,

I haven't looked at the code so this is based on recollection and your

> because I could also imagine wanting to handle the case where several
> programs handled the same set of arguments.  So maybe that would be
> something like ...
>     int smatch(const char **, const struct swit *, ...);
> Where the additional arguments might be something like:
> and you'd do:
>     smatch(&argp, switches, SMATCH_ARGV, post_switches, post_argv);

I'd tend towards using X-macros in a #define of an option set, e.g. a
standard one that includes -help and -version.  These can be visible
through a #include and interpolated into a program-specific set that
overall makes up what directs smatch2().  A program like post can make
visible a macro with a series of X-macros that are its options its
intends higher programs like send to use.

The X-macro can map onto what's required at the time.  The overall list
of options in send would then be the standard ones, send's ones, and
post's ones, and by default presented with that grouping and order,
e.g. in -help output.  That seems to be a feature.

Cheers, Ralph.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]