std.getopt suggestion

[Jens Mueller]

Nick Sabalausky wrote:
> "Jens Mueller" <jens.k.mueller at gmx.de> wrote in message 
> news:mailman.21.1317824685.28623.digitalmars-d at puremagic.com...
> >
> >I think we have failed, if a significant number of users rather write
> >their own command line parsing than using the built-in one.
> 
> I suspect that what often happens is what happened to me: The D user has an 
> idea of how they want their cmd line to work, they look at getopt and see it 
> won't work that way, so instead of changing their design to fit getopt they 
> just implement their own solution that actually does what they wanted in the 
> first place. (After all, it's not that hard to make a basic cmdline parser. 
> If it were harder then maybe more people would be succesfully strongarmed 
> into changing their design to match getopt's abilities.)
> 
> And I'm sure there are cases where a program actually needs to match an 
> existing program's command line for interoperability, in which case changing 
> the design to match getopt would not have even been an option in the first 
> place.
> 
> Encouraging a "recommended" way is admirable, but doing it by providing a 
> tool that allows the recommended way and then outright doesn't support other 
> ways is very anti-D-philosophy (and at best is going to annoy the very same 
> sorts of people who are attracted to D, and create more work for them). The 
> D-way (and IMO, the *right* way), is to make the "recommended" way the 
> default (and ideally even explain that it's recommended and why), and then 
> allow easy configurability for "heretical"-but-concievable uses.

And here it gets difficult. To support many different ways makes the
code complex and also the configuration process. Then we end up with an
extremely configurable solution that nobody uses because it's too
difficult to configure. Just think of the more manual pages to explain
it. Maybe things can be sorted out but after all it's just command line
arguments. For the moment I believe the easiest solution is to support
Posix and leave it to the user if they don't like it to implement their
own. Even better encourage people to create pull requests that extend
getopt.

> Of course, it's also the D-way to have a one-person veto carved in stone...
> 
> On a related note, does getopt support the ability to say "allow long 
> options that begin with *either* -- or /"? Since I make stuff that's 
> compiled natively to Windows (as opposed to being a clumbsy mingw-esque 
> "port"), that was important to me way back when, and IIRC may have been one 
> of the reasons I rolled my own cmdline parser a few years ago.

No. / won't be recognized as a long option.

Jens