Re: [boost] program_options: Support for open-end options

Subject: Re: [boost] program_options: Support for open-end options
From: ST (smntov_at_[hidden])
Date: 2013-01-13 10:39:26

On Sun, 2012-12-30 at 12:37 -0500, Rob Stewart wrote:
> On Dec 30, 2012, at 7:07 AM, ST <smntov_at_[hidden]> wrote:
> 
> > On Thu, 2012-12-27 at 10:28 -0500, Rob Stewart wrote:
> >> On Dec 26, 2012, at 12:56 PM, ST <smntov_at_[hidden]> wrote:
> >> 
> >>> It would be great to implement support for open-end options, something like that:
> >>> 
> >>> item_1 = 23
> >>> item_2 = 45
> >>> ...
> >>> item_N = 465
> >>> 
> >>> The idea is to to be able to provide following input: 
> >>> 
> >>> configOptions.add_options()
> >>>   ("item_", value<int>(), "items");
> >>> 
> >>> now if add_options() sees a key that ends with a "_" it accepts all options with keys that start with item_, no matter what comes after it, and treat all of them as int .
> >> 
> >> I think that's really odd, though I understand that you want something to allow a great number of options without defining them ahead of time.
> > 
> > Why is it odd?
> 
> Well, "odd" is a subjective word, but I'll try anyway. Your approach leads to duplication ("item_") for each option. I also generally like open-ended, or special-cased, lists of things to come last, not unlike C's ellipsis.
> 
> > I find it pretty intuitive/flexible and seems to be not that hard to implement.
> 
> Yours would be somewhat harder to document/specify in my estimation.
> 
> Implementation difficulty isn't particularly relevant (other than affecting the likelihood of its acceptance).
> 
> >> My first thought was a command line delimiter to introduce a list of such options:
> >> 
> >> ... --foo 1=23 2=45 ... N=465
> > 
> > My way this would be: --foo_1 23 --foo_2 45 ... --foo_N 465
> 
> I understood full well. Notice how mine makes the name/value pairs manifest, whereas the names are substrings in yours.
> 
> >> You'd specify "foo" as the delimiter and PO would then parse the remaining values into pairs to populate a map. Since the set of name/value pairs is open ended, they would always go last on the command line.
> > 
> > With my aproach there is no need for this limitation and you can have as many open-ended options as you like.
> 
> The part below allows for such a list to not be last, but my expectation is such should normally be last, so the end delimiter won't be needed normally.
> 
> >> Of course, you could also specify a delimiter to signal the end of the pairs. (If you want validation that the option names match a pattern, you can add that, too.)
> >> 
> >> To avoid the name/value pairs, the following could be used to populate a vector:
> >> 
> >> ... --foo 23 45 ... 465
> > 
> > Sometimes one wants to use strings to distinguish between such open-ended options and not numbers(indices of a vector in that case), for example:
> > 
> > --os_linux 435 --os_solaris 234 --os_mac 123
> 
> I understand, but I was illustrating how my approach could be modified slightly (by populating a vector rather than a map) to access the options by index when desired.
> 
> > In my specific case I need to have the ability to "see" options that were ommitied (on purpose), like:
> > 
> > # visible points and their current coordinates
> > [second_123]
> > point_1 = 12 45 1
> > point_5 = 65 23 23
> > 
> > [second_124]
> > point_1 = 12 47 3
> > point_4 = 212 565 12
> > point_7 = 122 453 157
> > 
> > So map is the right option here.
> 
> Of course. I wasn't suggesting to not use a map. However, another option in all of this is to just arrange for PO to collect all unrecognized options in a map keyed by command line position, leaving special case parsing to applications with unusual requirements. IOW, PO would be most extensible with such an ability, regardless of its ever gaining support for anything like you or I have mentioned herein.
I thought about it, but the problem with this approach is, that you'll
have to parse through the whole map for each group of open-ended
options. Abilitiy to provide seperate map for each such group, is better
IMHO.