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
Consider it added.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk