Re: [boost] Re: Re: Formal Review: Command Line & Config library

From: Pavol Droba (droba_at_[hidden])
Date: 2003-05-26 04:10:47

On Mon, May 26, 2003 at 10:41:08AM +0400, Vladimir Prus wrote:
> Pavol Droba wrote:
> 
> >> The only problem with current 'validator' is that it should validate
> >> *string* and return the value. So, the example given by Tanton:
> >> 
> >>    _1 >= 1 && _1 <= 9)
> >> 
> >> would not really work --- the validator function is given a string. It's
> >> probably possible to use 'notify' callback to do such kind of validation,
> >> though. Or add another validator --- which is given converted value.
> >> 
> > 
> > I see. However I think this is a little bit clumsy to use. I think it may
> > be better to strip validation from the conversion.
> > 
> > What I had in mind is an extension to po::parameter funtion to something
> > like
> > 
> > template< typename T >
> > *unspecified* po::parameter<T>(
> > string parameter_name,
> > T& variable,
> > const boost::function1<bool, T)& validator );
> > 
> > so the framework would convert string parameter to a specified type and
> > then run the validator functor on the result to validate it.
> 
> I was actually thinking about splitting current "validator" into 
> "interpreter", which converts string to value and validator proper. That 
> should allow to write
> 
>    desc.add_options()
>       ("compression", parameter<int>("n"), "compression quality").
>              validator(1 < _1 && _1 <= 9)
>       ;
> 
> With this feature in place, adding validator as additional argument to 
> 'parameter' can be considered a convenience. (Now, there are 3 ideas for
> additional arguments to 'parameter', so I can't decide right now).
> 
> One problem: the above would require implementation tricks. The value 
> extracted from string is stored in boost::any. Sure, you can't pass 
> boost::any to the lambda function above, so some means to recover the type
> stored in any would be needed. I'm not yet sure this will be all that big
> problem, though.
>

Ok, I think, I see now, where the point is. 

The framework is separated into two layers.

L1: option level ( string and boost::any oriented,  defined by option_description ) 
L2: typed-paramter level ( represented by po::parameter function )
                
L2 should work above the L1 as an optional feature
Currenlty L1 is quite well defined, but L2 is lacking.

I would like if L2 would be able to convert a string representation
to given type, run the typed validation and store the value into local variable.
Conversion and validation should be parametric with reasonable defaults.
Also, I think that the conversion and validation should be separated.
Conversion should deal with a format of a parameter, while the validation should
check semantic properties of its value.

Important is, that L2 should be separated from L1. So L2 conversion and validation
would be different from L1. Actually, L2 validation and conversion should plug into L1 
as a custom validator.

I hope this makes some sense. po::parameter ( aka L2 ) is quite close to the goal, but there
are still some missing parts.

[snip]
 
> Attached is a complete example which uses regex library to validate option's 
> value. The format of value is fictional, but the main idea should be clear. 
> And there's example session:
> 
>     bash-2.05b$ bin/gcc/debug/regex --help
>     Usage: regex [options]
>     Allowed options:
>       --help                 : produce a help screen
>       -v [ --version ]       : print the version number
>       -m [ --magic ] arg     : magic value (in NNN-NNN format)
>      bash-2.05b$ bin/gcc/debug/regex -m 123
>      invalid value
>      bash-2.05b$ bin/gcc/debug/regex -m 123-345
>     The magic is "345"
> 
> I've also realized there are no examples for custom validator now, so this 
> code will most likely be added to the library.
> 

Thanks for the example. It should definitely become a part of the documentation.

Regards,

Pavol