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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2001-12-10 08:42:31

David A. Greene wrote:
> Vladimir Prus wrote:
> >>Absolutely!  As I mentioned earlier on in this thread,
> >>
> >>I have found this sort of thing incredibly useful.  It's
> >>
> >>great for passing arguments to plugins, for example.
> >
> > To tell the truth, I find passing arguments to plugins
> >
> > relatively rare case.
>
> I can think of all sorts of applications that might want
> this.  Multi-format media encoders/decoders,
> compressors/decompressors, basically anything with a
> filter interface.  Filters are pretty common beasts.
> We use plugins in our research compiler to implement
> analysis and transformation passes.
  
Ok, this all are resonable applications. Dynamically loading plugins is 
something I have doubts about, but probably we can make it cleanly work -- 
see a proposal later.

> Passing
> configuration arguments to the plugins is critical for
> us, and we don't want to clutter main() with information
> about all of the modules.  Modules should take care of
> themselves.

Of cause.

> > This is the first case I hear about allowed arguments
> >
> > being dynamically computed, as  you tell in another
> >
> > message. Do you think it worth supporting in a general
> >
> > purpose library?
>
> It's worth it for our group.  :)  As for the rest of
> the community, I don't feel comfortable speaking for
> others.  Let's solicit some opinions.
>
> I'll say this: if an argument parser is going to
> provide support for nested arguments, then it might
> as well provide support for dynamically adding them
> at run-time, because it is trivial to do so.

To this I agree.

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? Dynamic loading is a 
problem (at least for me :-) ) because it will erase the distinction between 
syntantic and semantic phases. Currently the description of options is 
prepared and 
1) Command line is parsed, without *no* side effects.
2) Optionally, parsed command line is converted to some internal form and 
side effects like assignemnts to program variables are performed. 
I'd like to retain the distintion. For the benefit of plugins, I'd suggest 
this scheme:
1. Programmer defines a "loose" syntax: e.g. where any options starting with
"--scheduler." are allowed.
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.
Of cause, we'd need some convenient code for this process. This proposal has 
the good points of 
 - Meeting your requirements (I hope)
 - Not breaking the separation
I'd like to know what you think about it.

- Volodya