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 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 optionI 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.
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.
OK, that's possible, but quite uncommon. I'd pass the data via file.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.
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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
