Re: arguments parsing, wildcard matcher

From: Gennadiy E. Rozental (rogeeff_at_[hidden])
Date: 2001-11-20 01:56:19

--- In boost_at_y..., "David A. Greene" <greened_at_e...> wrote:
> >   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).
I lost me there. I think vice versa. First version unite 2 think 
while second separate argument identification and parsing from 
argument processing.

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

IMHO you will immediately find a bag of problems as soon as start 
mixing 2 things in one bottle. The design should encorage users to 
separate actions. Was the action performd while parsing a command 
line? What to do if user put arguments in wrong order? Or framework 
that smart that it will be able to handle any input? We should not 
make a very smart (and very complex appropriately) components by 
itself. If it possible we could try to place a hook for extentions. 
And everybody could make parser as smart as thay need.

Regards,

Gennadiy.

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