[boost] Re: Preliminary submission: command line & config file library

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-01-28 10:57:53

David A. Greene wrote:
> Vladimir Prus wrote:
> 
>>> I have one policy that I forgot to mention: chain_lookup_policy. It's 
>>> work
>>> is based on Chain of responcibilities Design pattern. In this case Every
>>> parameter knows how to parse itelf out of input. And this 
>>> identification may
>>> not be the name at all.
>>
>>
>> I would say that it's a big question how much flexibility is needed. 
>> My position is that the command line should not go beyond existing 
>> styles.
>> Can you suggest some style which require chain_lookup_policy and still
>> legible for users?
> 
> 
> If I understand what Gennadiy is saying, then I have a possible example.
> Our compiler has options that look something like this:
> 
> -fcopyPropagation={--maxTransforms=32 --keepStats}
> 
> Nobody but the CopyPropagation module should care about what's in
> the braces.  "-f" knows enough to parse a filter name ("copyPropagation"
> in this case).  These constructs can be arbitrarily nested.  One of our
> modules goes three deep, IIRC.

Hmm... that's pretty interesting example. While I'm not sure how Gennadiy's
code can handle such things, I have some ideas w.r.t my library.

1. You'd need some way to extract those composite options from the command 
line. I assume that matching braces suffice. Then, you'd write an additional
parser (just a function), which can extract "copyPropagation" and
"{--maxTransforms=32 --keepStats}" from the above option. That function will
be passed to the command line parser.

2. Since you say that only CopyPropagation module should care about content of
    braces, I think that module can simply register option "copyPropagation"
    and a custom function ("validator"), which will be responsible for
    interpreting the content of value. For example, it can split the content
    on whitespaces and parse it like a command line of it's own.

The only problem with this scheme is that now additional parser can operate on
one token only. However, this restriction is not fundamental and can be lifted 
easily.

How does the above suggestion look?

- Volodya