[getopt-sig] Comparing option libraries

[Matthias Urlichs]

Hi,

A.T. Hofkamp:
> I think you are doing a terrific job of answering all issues raised in this
> SIG, many thanks for that.
> 
So do you, right now. Thank you.

> An option object (i.e. an instance of an option class) represents a single
> command-line concept.

I like that concept. It translates rather nicely to interdependent
options -- "build a subclass which handles all of them".

>   The current ripoff program implements the policy that 'the last setting is
>   valid', i.e. if a user specifies 'ripoff --file --pipe', it is considered to
>   be equivalent to 'ripoff --pipe'.
>   I disagree with this equivalence notion. If a user specified both options, it
>   is likely that he wants both options.

I agree.  IMHO it is important not to have silent override options
_in_the_same_context_.

The same story happens with --quiet/--verbose. If somebody specifies "-q
-vv" then that should be an error. However, if the configuration file says
"-v" and the command line "-q", that's OK.

Configuration files, however, are NOT command line options. A config file
should not be forced to look like a command line just so that the command
line parser is happy.

>   Very rough, untested implementation:
> 
Looks sensible, except for the typo:  ;-)
>         return _NOMATH


> - Is the idea of 'an option object represents a single concept' good ?
> - Should we have a seperation between usage and value of an option ?
> 
Yes, and (probably, but that's just me) yes.

> PS With your comparison page, you suggest some form of competition. I do
> not have that intention.

Line count is a (albeit imperfect) measure of complexity.
Command line argument handling should be as simple as possible, but no
simpler. ;-)

-- 
Matthias Urlichs     |     noris network AG     |     http://smurf.noris.de/
-- 
Backup not found: (A)bort (R)etry (P)anic