Re: Any interest for a parser class?

From: rogeeff (rogeeff_at_[hidden])
Date: 2002-01-18 15:51:02

> >--- In boost_at_y..., "Stewart, Robert" <stewart_at_s...> wrote:
> >> [...]
> >> Any interface that allows users to add custom argument handling 
> >> exposes some sort of parsing implementation. 
> >
> >That is a key point. This statement is false.
> 
> Only in the most technical sense.
> 
> >class argument can have interface like this:
> >class argument {
> >public:
> >     virtual bool match( argv_stream_iterator it ) = 0; 
> >     virtual void construct( argv_stream_iterator it ) = 0; 
> >};
> >
> >argv_stream_iterator is an iterator over stream constructed from 
> >argc,argv. 
> >
> >That's it. Framework has list of arguments and do something liek 
this:
> >
> >while argv_stream is not empty
> >
> >for each argument 
> >{
> >    if ( argument match ) {
> >         if another argument match => error
> >         construct argument
> >         if fail to construct => error
> >         break 
> >    }
> >}
> 
> So instead of giving the user a way to specify the parsing
> format, and letting the CLA framework continue to do the
> parsing, you would rather offload the actual parsing responsibility
> to the user. 

In most case end-user would use predefined rich arguments set. More 
over each argument could be parameterized with identification policy.

>  If I wanted to parse my own CLAs, why on earth am
> I including a library?  To store my arguments?  

it' CLA framework. Store, validate and destroy an arguments, provide 
an access and so on

> What if I have a
> nested option hierarchy?  

Generic framework could provide support for nested arguments. Note 
that it has nothing to do with parsing.

> Am I to handle all that complexity
> myself, as an end-user, or are you going to let me specify how
> options interact?

Generic framework could provide support for dependent arguments. Note 
that it has nothing to do with parsing.

> 
> Dave

Gennadiy.