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

From: Pavol Droba (droba_at_[hidden])
Date: 2003-05-26 05:34:31

On Mon, May 26, 2003 at 02:07:06PM +0400, Vladimir Prus wrote:
> 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
>

This sounds very reasonable. 

I would suggest that L2 should be interfacing to variables_map, to allow 
cascading of different input formats formats. I don't know how is this 
feasible though.

Also, typed 'default-value' should be considered as parameter of L2 definition.
 
> > 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?

Definitely, logical separation of levels is an important concept of the libary.
It has to be documented, otherwise users get confused.

Pavol.