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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-01-16 04:52:30

Rozental, Gennadiy wrote:

>>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.
> 
> 
> Could you list all existent styles? 

I think you did so yourself, in a message included in the doc directory
of my submission. Few other styles were added by others.

> Does your parser supported all of them?

Maybe not. However, the unsupported one probably differ on in prefix
("/" vs "-"). And something really custom ("-fno-unsigned-char") can
be handled via "additional_parser" mechanism (there's an example of it in
the documentation.

>>Can you suggest some style which require chain_lookup_policy and still
>>legible for users?
> 
> 
> For example, one what in one parser mix of named and positional parameters.
> Every token that does not fit for any named parameter will be considered
> positional (the same effect though could be achieved with 2 separate parsers
> - but you asked for example)

The fact that the same functionality can be achived in another way, makes this
example less convinving.

>>I don't know how to compare number of people who need command 
>>line to the 
>>number of people who *also* need config file. I suppose that 
>>as your program
>>grows bigger, you're likely to need config file too. The 
>>transition should
>>be simple.
> 
> 
> And again I argue that at least 90% of cla framework users will never have a
> need for anything else (IMHO). That does not mean that we should not provide
> support for reading of config files - just no need to couple them together.

I did not say that should be coupled. But you'd need something which keeps 
option description independent from parser. You design seems much more 
coupled: the code which parsers the options, the code which keeps option
description and the code which keeps the resulting value is all in "lookup 
policy".

> 
> 
>>"parameter extraction policy" or "parameter search policy" 
>>sound better.
> 
> 
> How search policy is better than lookup policy?

"lookup" sounds like "lookup in a map/hash" or "lookup in database".
"search" can be "search in a string/container" -- a better match for
command line.

(It looks like two non-native speakers are likely to get naming wrong,
  anyway)

> 
> 
>>Oh.. it's even more complicated! Are your command line 
>>syntaxes that complicated?
> 
> 
> No. But this way I could parse out UDT from command line input.

That's *very* complicates solution. Assume I'm parsing "FontName" class

    --font=times-*-koi8

All I need to parse this out, is to declare operator>> for FontName. The
problem with spaces is overcome by quoting.

>>>my_program <debug>true</debug> <delay><seconds>2</seconds></delay>
>>
>>Do you really think that there is *one* user who would be happy with
>>this command line style?
> 
> 
> Well, you easily agree that XML could be used in config files, but could not
> imagine it's usage in command line?
> What if the command line is auto generated?
> One may want to use XML style cla to supply complex multi level arguments,
> for example.

OK, that's possible, but quite uncommon. I'd pass the data via file.

But really, you got be quite confused by now. First you say that 90% of
users don't care about command line, and now you give really uncommon 
examples. I understand that you're trying to say that your framework allows
abribtrary customization, but I suspect 99% users will never need it, and
therefore it will be only additional section in documentation.

- Volodya