Command-line arguments

[Steven Schveighoffer]

"superdan" wrote
> Steven Schveighoffer Wrote:
>
>> "superdan"  wrote
>> > Steven Schveighoffer Wrote:
>> >> There is a new one in Tango as of the latest release called Arguments.
>> >> It's
>> >> very simple to use:
>> >>
>> >> auto args = new Arguments(argv[1..$]);
>> >>
>> >> if(args.contains("c")) {} // test for -c
>> >> auto filename = args["f"]; // get parameter for -f filename
>> >>
>> >> Of course, you can also configure it to be more strict, or to change
>> >> every
>> >> detail, down to the switch character (instead of '-'), but it is easy 
>> >> to
>> >> use
>> >> to get something up and running quickly.
>> >>
>> >> http://www.dsource.org/projects/tango/docs/current/tango.util.Arguments.html
>> >
>> > yarp looked over it. with all due respect, what a piece of crap that 
>> > is.
>> > with that i can't even hope to parse the command line of ssh or rdmd. 
>> > it
>> > loses the original order. it doesn't understand -- which in unix means
>> > that options stop here. generally does not obey new unix conventions.
>> > defines all sort of useless shit like conflicts that i could care less
>> > about. i could write one test expression after parsing thank you very
>> > much. but it cannot force the types of its arguments so i must make 
>> > sure i
>> > validate /all/ that shit which is much more voluminous. geez. finally 
>> > it
>> > defines so many types and functions anyone will need a fucking graduate
>> > course to use it. no thanks. std.getopt mops the floor with it.
>>
>> Piece of crap is a little harsh :)
>
> i agree it is harsh but i am dead serious. the problem is, tango people 
> should not allow people who can't design add stuff to tango. i look at 
> both option parsing stuff in tango and i get thinkin' of american sedans. 
> you look at an american sedan and you clearly can say it looks like a 
> vicious piece of shit. but it's hard to tell why. maybe if they raised the 
> trunk a little? the headlights should be placed differently? no idea. it 
> just sucks ass because it's designed by someone who can't design. the 
> design is so messed up you can't pinpoint a couple of flaws. the right 
> solution is to throw the whole thing and bring in someone who can design.

I happen to think it is well-designed for being as flexible as it is.  Like 
many things in Tango, it has the ability to adapt to 95% of requirements and 
still be easy to use.  I stopped using Phobos after about a week because in 
order to support the types of things I was doing with sockets, I needed 
functions that Phobos didn't abstract.  Tango handled the job extremely 
well, and I can't say I miss anything in Phobos.

>
>>  It can do some things that std.getopt
>> cannot, and the interface is loads better than the original ArgParser 
>> that
>> Tango had.
>
> to be 100% honest the original stuff that ArgParser had set the bar real 
> real low. and again. maybe an american sedan could do something that 
> others can't. maybe it has a neat ac control or a cool steering wheel or 
> shit. would i drive such a piece of shit for that? hell no.

The defaults for Arguments are really easy to use and follow the unix style. 
You have pointed out several things missing from the implementation that can 
easily be added.  In addition, Arguments has lots of extra features that can 
be useful if you need to have them.

And let's stop the whole car analogy.  If I get a shitty ac control on a 
car, I'm pretty much stuck.  Code can always be changed/added to :)

>
>>  The issue I have with getopt is that it forces you into a
>> specific option style.  This can be unacceptable if you are required to 
>> use
>> another style (by your employer for instance).
>
> if your employer wants to override tried and true de facto standards then 
> it's their problem. that comes with custom code for handling args, steeper 
> learning curve for use, and more user annoyance. i fail to see how that's 
> a problem with std.getopt.


Try using std.getopt with a windows application where the requirements state 
that you have to use '/' instead of '-' for arguments.  And telling your 
employer/client to go screw because they are idiots for not realizing POSIX 
style arguments are God's gift to man doesn't usually blow over well.

This is very simple in Arguments.  I agree that getopt is well-designed if 
the unix style of arguments is exactly what you want.  But if it isn't, you 
must write your own (or use Tango).  I prefer not to reinvent the wheel for 
every application.

>
>> Plus, with all the arguments
>> contained in one object, and all the validation being configurable on the
>> object instead of writing some piece of code after parsing, the arguments
>> can be very modularized, and reduced to simple functions.
>
> "modularized"? there is one command line per app. there is no need to 
> modularize anything. you modularlize if you use several instances in 
> several places. with command parsing all i want is to parse my args and 
> move on. in fact i *want* to put my validation right there in clear 
> instead of modularizing it away.

What about standard options?  GNU has these, and why should you rewrite the 
same code for every app?

>
>> BTW, does getopt preserve order?  It doesn't look like it from the docs.
>
> no but it understands -- and also has stopOnFirstNonOption. that's all 
> that's needed.

This behavior can be added easily enough.  Again, you point out features of 
getopt that are not features of Arguments, but are not prevented by the 
design of Arguments from being added.  These are 'feature' requests, not 
'design' requests.

-Steve