here's another possibility:
value<type>(&variable, "filename")->......
something like that was in the pre-review version, with the difference that the value name was also used to specify flags, e.g "filename?" would mean the value is optional.
Yes ... I like this best.
Also, I'm not sure why 0-argument items couldn't appear in a config file. I declare the number of arguments used by options before I parse the config file, after all.
Because the current config parser, systantically, requires that everything specified there has a value. If you specify that an option accepts no explicit value, it can't be present in config file.
OK, your statement was with reference to the current config parser ;) A newer parser could recognize the end of an option name first, then interrogate the option to see if it takes an argument, then if it does, expect to parse a "= value".
Hi Jonathan,
here's another possibility:
value<type>(&variable, "filename")->......
something like that was in the pre-review version, with the difference that the value name was also used to specify flags, e.g "filename?" would mean the value is optional.
Yes ... I like this best.
Ok, noted.
Also, I'm not sure why 0-argument items couldn't appear in a config file. I declare the number of arguments used by options before I parse the config file, after all.
Because the current config parser, systantically, requires that everything specified there has a value. If you specify that an option accepts no explicit value, it can't be present in config file.
OK, your statement was with reference to the current config parser ;)
Sure.
A newer parser could recognize the end of an option name first, then interrogate the option to see if it takes an argument, then if it does, expect to parse a "= value".
Hmm... that would mean that you can specify a value in config file for an option which does not allow a value? E.g. ("foo", bool_switch().... and then in config file: foo=false then "false" will be just ignored? OTOH, it might be reasonable to decide that the desired number of tokens applies only to command line, since other sources don't have any parsing ambiguities. - Volodya
A newer parser could recognize the end of an option name first, then
interrogate the option to see if it takes an argument, then if it does, expect to parse a "= value".
Hmm... that would mean that you can specify a value in config file for an option which does not allow a value?
E.g.
("foo", bool_switch()....
and then in config file:
foo=false
then "false" will be just ignored? OTOH, it might be reasonable to decide that the desired number of tokens applies only to command line, since other sources don't have any parsing ambiguities.
Actually, I was suggesting that a value for an option that doesn't accept one, would be a parse error. Otherwise you have possible confusion with user thinking it's a value<bool> and by saying foo=false, you mean the same thing as not specifying the "foo" switch. What's the use of an option with an OPTIONAL value? :) Wouldn't you just omit the option and use the default value if you didn't want to provide one? It should be possible to specify options, at command line or in config file, that have no value; their presence or absence (often, commented or uncommented in standard practice) would determine the value. I mean, a config file could have: value_opt=23 bool_switch_opt ... (not bool_switch_opt=something) It would be perfectly pleasing to me though, to allow bool_switch to have a true or false value in a config file, and not at the command line. However, that would violate the existing design, wouldn't it?
Jonathan Graehl wrote:
Actually, I was suggesting that a value for an option that doesn't accept one, would be a parse error. Otherwise you have possible confusion with user thinking it's a value<bool> and by saying foo=false, you mean the same thing as not specifying the "foo" switch.
What's the use of an option with an OPTIONAL value? :) Wouldn't you just omit the option and use the default value if you didn't want to provide one? It should be possible to specify options, at command line or in config file, that have no value; their presence or absence (often, commented or uncommented in standard practice) would determine the value.
It's possible for the absense of option and presense of option with no explicit value to mean different things. For example: - no '--compression' means no compression - ' just '--compression' means default compression level - '--compression=4' means the specified compression level But one has to try hard to achieve this behaviour. I though about removing optional values at some time, but never got to this. What do the users think? Does anybody need optional values?
I mean, a config file could have:
value_opt=23 bool_switch_opt ...
(not bool_switch_opt=something)
Yea, that's a possibility.
It would be perfectly pleasing to me though, to allow bool_switch to have a true or false value in a config file, and not at the command line. However, that would violate the existing design, wouldn't it?
Right, that's why I'm not sure what to do. There's a related issue. It's no possible to specify a list of things in config file. For example, you can't write include=a,b,c,d (or some other separator). You need: include=a ... include=d - Volodya
participants (2)
-
Jonathan Graehl -
Vladimir Prus