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

From: David A. Greene (greened_at_[hidden])
Date: 2001-11-20 10:24:55

Gennadiy E. Rozental wrote:

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

What I mean is that there is a section of code that registers the
options, and (possibly several other) sections of code often in
completely separate files that actually implement the actions
if the options are seen.  The programmer need not worry about
writing "if (argument.is_present())" because that implicitly
happens when the option parser is invoked.  If an option is
given, its action is invoked.  There is no centralized option
processing loop in main().  I find this to be a nice separation,
but YMMV.

>>We often want to do a lot more than just know if a switch
>>has been set.  

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

You lost me.  How does variant 1 not encourage this?  I guess
I'm being dense.  What two things are being mixed?  Parsing
and processing?  I guess I find those natually interlocked.
Model 1 does not preclude separating them.

> Was the action performd while parsing a command line? 

Um...huh?  Currently, yeah.  This could change, though.  See
below.

> What to do if user put arguments in wrong order? 

Well, as I said the convention can be changed.  I'm just describing
what I have now, which is what I have experience using.  I'm not
claiming it's ideal.  It should be realtively straightforward
to parse all the options and then invoke the actions in some
programmer-defined order.  The programmer can pass this ordering
to the parser or some other entity.

> Or framework that smart that it will be able to handle any input? 

What do you mean by "any input?"  Currently it does not support
the myriad of option formats, but that's because I find the
--long_option=value format to be most clear for what I need to do.

> We should not make a very smart (and very complex appropriately) 

> components by itself. 

It's really not all that complex.  It's rather nice in that options
and option trees are the same class.  Any option can have a
subtree.  Yes, the parsing can get messy, which is why I moved
over to a more formalized framework.  It was a convenience _for_me_
and is not necessarily appropriate for everyone.  But perhaps
this _is_ an indication that things are too complex.  I did manage
to implement it without yacc, however.

> If it possible we could try to place a hook for extentions. 
> And everybody could make parser as smart as thay need.

That would be ideal, of course.  I'm simply enumerating the
features I am currently using.  Any cmdline library that
doesn't handle them is going to be next to useless to me.
But that's ok because I have what I need already.  I'm simply
pointing out features that might be useful to others, things
we might want to consider in any design.

Thanks for your input, though.  You've given me some things
to think about.  :)

                               -Dave

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