Re: [boost] Re: arguments parsing, wildcard matcher

From: David A. Greene (greened_at_[hidden])
Date: 2001-12-10 12:22:35

Vladimir Prus wrote:

 > Let's try to find what is needed actually. A while ago to configure
 > subcomponents I was actively using very simply approach --
 > hierarchical naming, e.g. options that look like:
 > --scheduler.ordering=sms
 > It was sufficient for my purposes. It is ok for you?

Yes, that's pretty much what I have used as well.

 > Dynamic loading is a problem (at least for me :-) )
 > because it will erase the distinction between
 > syntantic and semantic phases.

I understand the "academic" reasons for this desire, but I
wonder if it is too restrictive in practice.  My primary
design goal for an argument parser would be easy to use.

 > 1. Programmer defines a "loose" syntax: e.g. where any options
 > starting with "--scheduler." are allowed.

I don't quite follow you here.  To make it more concrete,
are you saying the "loose" syntax should be something like
"--plugin<name>=<plugin_options>" (don't worry about the
syntax now, just the idea) where there's a "well known"
"--plugin" option that can be used to specify a plugin to
load and options to pass to it?  This is essentially
what we have done.  Ultimately the programmer defines
what the "well known" interfaces are (--scheduler could
be a special kind of plugin, for example).

 > 2. Command line is parsed.
 > 3. Options are examined, and the set of required plugins is computed.
 > 4. New options description is computed, this time asking loaded 
plugins about
 > exact syntax.
 > 5. Syntactic and semantic parsing is performed.

This sounds reasonable to me.  The way our system works,
when the "--plugin" option is parsed, the plugin is immedately
loaded and a method is invoked for the plugin to add
its options to the tree.  The parser then traverses the rest
of the --plugin option string (i.e. the arguments for the
plugin).  Since the plugin added its arguments to the
tree this should succeed.

It's essentially the system you describe except that, as
you note, the syntax and semantics are mixed.  I am starting
to like your separation idea.  The academic in me is
starting to show.  :)

That said, I still don't like this sort of syntax:

parseOptions(argc, argv);

if (wasPassed(options, "some-option-name")) {
    doSomeOptionNameAction();
}

I think it is too verbose and error-prone.  I still much
prefer this:

options.register("some-option-name", "some-option-help",
                  someOptionSemanticActionFunctor());

options.parse(argc, argv);

It keeps everything more "together."  The semantics
invocation can still be delayed with the model.

But this is of course just IMHO.  Maybe Boost could
allow both?

                               -Dave

-- 
"Some little people have music in them, but Fats, he was all music,
   and you know how big he was."  --  James P. Johnson