std.getopt suggestion

[Andrei Alexandrescu]

On 10/1/11 5:42 AM, Jacob Carlborg wrote:
> On 2011-10-01 00:17, Andrei Alexandrescu wrote:
>> On 9/30/11 12:23 PM, Jacob Carlborg wrote:
>>> On 2011-09-30 19:39, Jose Armando Garcia wrote:
>>>> On Wed, Sep 28, 2011 at 12:44 PM, Jonathan M
>>>> Davis<jmdavisProg at gmx.com> wrote:
>>>>> So, my suggestion is that we create a GetOpt struct which contains
>>>>> all of the
>>>>> options for getopt, and we make getopt a member function of that
>>>>> struct.
>>>>
>>>> Making it a struct gives you a design flexibility that really is an
>>>> illusion. Most people it not all people use getopt to parse command
>>>> line param. Giving the user the flexibility to have multiple GetOpt
>>>> with different configuration when in essence they are parsing the same
>>>> share resource (the command line) is incorrect.
>>>
>>> I don't agree. Take this command line for example:
>>>
>>> "foo -a bar -b"
>>>
>>> You're calling the "foo" tool with the global "-a" option, the "bar"
>>> command/action and the "bar" specific "-b" option. This is how I would
>>> implement that (I have no idea if it's possible with getopt but lets
>>> assume that for now):
>>
>> It is possible, and rdmd does that by using the stopOnFirstNonOption
>> flag.
>>
>> Andrei
>
> I forgot to mention that I don't want the order of the arguments to
> matter. I should be possible to write:
>
> "foo bar -b -a"
>
> Or at least it should be possible to put global options anywhere in the
> command line.
>
> So I guess that would be using the passThrough option the first time
> getopt is called and then using the noPassThrough option when it's
> called the second time from the action implementation.
>
> So there we have a use case for calling getopt more than once, at least
> I have a use case for that.

Clearly there are legit use cases. The use of monostate does not impede 
them.

Andrei