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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-01-17 05:12:08

I'm sorry for extremely delayed reply -- I've missed the message I'm 
responding to.

David A. Greene wrote:
> 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.

Good.

>  > 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.

Another attactive aspect of separation is that it would allow to write an 
*extremely* lightweight syntax parser, that will be usable separately. I 
guess someone will want to use only it, without any semantic features like 
validation.

>  > 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).

Looks like we're of the same mind here.

>  > 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.  :)

Good. Probably, we can refine the design for mutual benefit :-)

> That said, I still don't like this sort of syntax:
>
> parseOptions(argc, argv);
>
> if (wasPassed(options, "some-option-name")) {
>     doSomeOptionNameAction();
> }

Sorry, but it is *not* my syntax.

> I think it is too verbose and error-prone.  

True!

> 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.

Well... except for some details, this is the same method of describing 
options that I use!

- Volodya