[boost] Re: Re: program_options lib review

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-05-23 04:03:28

Hi Tanton,

Tanton Gibbs wrote:

>> > Here are my addressable comments
>> > (1) I would like to have a find_if and count_if function as I often
>> > want to
>> > find a parameter of the format *.field.*  It doesn't matter what the
>> > *'s are
>> > as long as it contains .field.  They should both take a function as a
>> > parameter.
>>
>> Those functions should be added to variables_map, right?
> 
> correct.

Adding those functions is OK with me. But could you describe an example
where they are needed. I would like to have most features to be backed up
by some motivating example (probably even documented).

In particular, I wonder how parameters of *.field.* format get into
variables_map. If they come from command line, you need to register
all possibilities, usually. 

>> I think 'parameter' function should not take arbitrary parameter, or
>> we'll be lost in overloading ambiguities. However, user or I can write
>> more functions, similiar in spirit to 'parameter', but with added
>> semantics. E.g:
>>
>>    desc.add_options()
>>         ("compression", range_parameter("n", 1, 9), "desired
>>         compression") ;
>>
> 
> I would rather see something like
>       desc.add_options()
>           ("compression", parameter("n", (_1 >= 1 && _1 <= 9)), "desired
> compression")

I agree that's nice. In fact, even now you can specify arbitrary functional
object to convert value from string to desired type, and to validation of
the fly. What is missing is separate function to validate only *value*, as
you do above.

> I think that is infinately more flexible.  There is no possible way you
> could imagine how people want to validate.  However, if you wanted, you
> could provide shortcuts.
>       desc.add_options()
>           ("compression", parameter("n", in_range(1, 9)), "desired
> compression" )

The "range_parameter" function I was talking about is precisely that ---
shortcut for more verbose setting of validator.

>> > (4) What if I want parameters to occur in a particular order?  For
>> > example, the -kk option can only occur after the update parameter in
> cvs:
>> > cvs update -kk blah blah blah is legal
>> > cvs -kk update blah blah blah is not
[...]
>> Something like that could be added, but I'll try to do that only if
>> seriously pressed by some user. The reason is that I find such command
> line
>> syntax to be confusing. As I've mentioned some time ago, in CVS the same
>> option means different things depending on position and this leads to
>> user confusion, not convenience.
> 
> I understand this and won't quable over it.  It definately has its
> downsides, but there are programs that use it and it would be nice to say
> the lib supports it.  And, FWIW, I still have trouble with cvs command
> lines
> :)

:-) 
Ok, then this feature is postponed until need arises.

- Volodya