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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-05-26 05:07:06

Pavol Droba wrote:

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

I completely agree. Basically, this means splitting the current "validator"
in two, as your describe above. Plus some polishing of interaction between
  'convert'/'interprepter'  -- for string->type conversion
  'validator'  -- for checking the value of desired type
  'notifier' -- which does storing into local variables

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

Yep, that makes complete sense. By default, L1 simply converts strings from
command line to strings inside variables_map. The converts/validators that
come from L2 make it behave in more usefull way. 

Do you think those levels must be explicitly written down in docs?
 
>> 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.

Consider it added.

Thanks,
Volodya