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

From: David A. Greene (greened_at_[hidden])
Date: 2001-11-19 22:17:14

Gennadiy E. Rozental wrote:

> program. Can you imagine that all your programs will require Spirit 
> Framework to compile and run? I think we could use the following 

Oh, I'm not saying we can't design it to be componentized in
some way.  I'm throwing out ideas, _not_ anything close to
a final design.  The last thing I'd want to do is upload
the code I have.  It is _not_ the sort of thing we want in
Boost, I think.

The parser framework is just a convenient way to, well, parse.  :)
An older version I have uses good ol' manual string processing.
It gets a bit ugly with nested options, though, which is why
I wanted a more formalized approach for the applications
I've been working on.  I wouldn't use it in something like
tar.  :)

>   For example to register an action for particular argument presence 
> you will need somethink like:
>      new argument( ..., do_this_action_if_present() );
> While the same logic could be implemented like this:
>    if( argument.is_present() )
>      do_somethink();
> 
> The second version is also more stable because you now know in which 
> order events will ocure.

Hmm...I prefer the first because things are logically separated
(defining what the option keywords are and defining what they do).

We often want to do a lot more than just know if a switch

has been set.  I can imagine situations where the meanings of
switches changes based on what other arguments are present.
There is an ordering issue, yes.  The processing order is defined
by which order the arguments appear on the command line.  Perhaps
not ideal but some other convention could be defined.

I'm brainstorming here, not presenting the One True Way.

                              -Dave

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