std.getopt suggestion

[Jacob Carlborg]

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):

class Application calls getopt once with the "sloppy" option. This will 
handle all options this "instance" of getopt knows about, the rest will 
be untouched. Now we have this command line:

"bar -b"

The Application slices off "bar" and invokes the bar command, i.e. 
calling some method in the Bar class.

Bar has its own "instance" and settings for getopt. Bar will call getopt 
with the "strict" option on what's left of the command line: "-b". Bar 
now handles the "-b".

If an invalid option is passed the Application class will ignore it 
since the "sloppy" option was set and passed it through to the action. 
The action will then loudly complain if an invalid option was passed to 
the tool since it called getopt with the "strict" option.

-- 
/Jacob Carlborg