option processor design decision

From: Sven M. Hallberg (pesco_at_[hidden])
Date: 2001-05-14 07:22:48

I'd like to discuss the following design question(s):

1. Should the option processor modify argc/argv, i.e. removing all options it
   processes?
1a. Should options that generated an exception (due to a syntax error or
    thelike) be removed also?
2. Should it even be passed argc/argv directly or maybe an iterator pair?
2a. If an iterator pair was used, how is the user supposed to get at the
    non-options?

Idea A:
 Pass argc/argv. Remove all options recognized as such, regardless of
 exceptions.
 Situation:
  - argc/argv can be used after processing as if there had been no
    options.
  - Resuming an interrupted processing run (due to an exception) is achieved
    simply by calling the processor again on (the modified) argc/argv.
  - Control over options is passed completely to the option processor,
    information about the _exact_ command line args is lost.
 Pro:
  - slim (^= simple) user code 
  - completely transparent option processing
  - simple to resume
 Contra:
  - limited flexibility
  - Effects on intermangled non-option args are impossible.

Idea B:
 Pass a pair of random access iterators. Move all options to the beginning
 during processing. Preserve their order. Return the number of options on
 success. In exceptions include the index of the option that generated the
 error.
 Situation:
  - After successful processing, simply adding the number of options to the
    first iterator yields the sequence of nonoptions.
  - On error, the index provides access to the erroneous argument, as well as
    the next argument, using which the processing can be resumed.
  - The order of options intermangled with non-opts is lost.
 Pro:
  - User code overhead (on success) is tiny.
  - Error handling (including resume) is simple but flexible.
 Contra:
  - Effects on intermangled non-option args are still impossible.

After examining the Situation I propose Idea B.
Rationale:
 Summarizing the differences to Idea A:
  - Complete transparency is lost. Generality to sequences is gained.
  - Complete encapsulation of the process is lost. Flexibility is gained.

 Loss of transparency means that one can no longer write the program as if
 there was no option handling (except for the processing code itself). Looking
 closer, however, reveals that the point after which the above effect appears
 is just shifted down by a couple of code lines:

      // make argc/argv look more sequence-like
      typedef char* Arg_iter;
      Arg_iter arg_begin = argv+1;
      Arg_iter arg_end   = argv+argc;
      // [... processing code omitted ...]
      arg_begin += optcount;  // remove all opts from the arg sequence

 After that the iterators arg_begin and arg_end again denote the sequence of
 non-option arguments as if there had never been such a thing as command line
 options.

 Loss of complete encapsulation means that one can no longer just pass the
 arguments to a magical gadget called option_processor and forget the issue.
 One must remember what the argument sequence is and what exactly it contains
 before _and after_ invoking the processor. Of course this is a price, but
 merely one that belongs in the RTFM-department. It can be expected of a
 programmer to know what command line options are. :)

 The last point to ration out is the one common to Idea A and B: the loss of
 information about non-opts intermangled with the options. I argue that there
 is _no_ need for that information, because the things that those non-opts are
 intermangled with in this scenario are not to be considered options.

 My definition of an option is:

     An optional setting which causes a certain modification to a program's
     general behaviour.

 Options should apply to the program's behaviour, not command line arguments.
 Attaching properties to a program's arguments is an area entirely different
 from option handling.

Comments requested!

Sven

-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]