July 05, 2008
Dee Girl wrote:
> more types should not add without necessity.

It's a matter of style. If you ever use Smalltalk, adding types is the preferred way to represent any piece of data that associates logic.
July 05, 2008
On Sat, 05 Jul 2008 06:05:39 +0100, Dee Girl <deegirl@noreply.com> wrote:
>
> Also the modular part is not good argument. Code to handle command line is unique, never called from the app. Only once. Should be there in line. Design for modular there is not justified. I think even is mistake. Parse arguments is simple problem and should have simple solution. std.getopt is simple solution. (only one function!) All other are complicated. It means they did not see how simple problem is. Thank you, Dee Girl

Code to handle *a* command line is not always unique. argv is only one possible
source. Imagine you are implementing a shell with several builtin commands. These
commands will have options that need to be parsed.

Still if I had to vote and it was based purely on the discussions so far (ignoring the rudeness)
I would go for getopt. Fortunately getopt in D is nothing like the gnarly beast that getopt is in C.

I don't think the three items required by getopt are redundant. They provide different information.
The variable declaration gives the type. You could only avoid this by making arguments a special type
like stringArg: public Arg which tends to overcomplicate things.
As has already been pointed out there is not necessarily a one-to-one mapping between the variable name
and the option name. Especially if you have different conventions to conform to for your user interface
and your code. Assuming your users always have the same requirements as programmers is a bad thing.
That said providing a default mapping and a way to override it does make sense.

None of the discussion so far has provided a decent use case for why we need C# style attributes or
even a definition of them for those in the group less familiar with them. If there is one I doubt its
going to come from the command line.

Regards,

Bruce.
July 05, 2008
superdan wrote:

> Lars Ivar Igesund Wrote:
> 
>> superdan wrote:
>> 
>> > Lars Ivar Igesund Wrote:
>> > 
>> >> As for preserving and enforcing order, that was one of the design goals for this implementation and thus it should be considered a bug if not easily done.
>> > 
>> > put in layman's terms: making it unusable for applications that launch secondary commands was a design goal.
>> 
>> No.
> 
> then parse this using tango arguments please:
> 
> ssh -v ls -la
> 
> thanks.

Everything until ls is easy (including the hostname which is required by ssh), but it appears to ignore the -la part which I have noted to the implementors. I believe I did say that although the requirments document (I probably wrongly said design document) mandates that this should be possible, the implementation and design is not fully reviewed yet and may have bugs.

The order is completely preserved and enforcable though.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
July 05, 2008
Lars Ivar Igesund wrote:
> superdan wrote:
>> then parse this using tango arguments please:
>>
>> ssh -v ls -la
>>
>> thanks.
> 
> Everything until ls is easy (including the hostname which is required by
> ssh), but it appears to ignore the -la part which I have noted to the
> implementors. I believe I did say that although the requirments document (I
> probably wrongly said design document) mandates that this should be
> possible, the implementation and design is not fully reviewed yet and may
> have bugs.
> 
> The order is completely preserved and enforcable though.
> 

What about "ssh -v -- ls -la", I wonder.

Actually, I don't wonder. The documentation says that the empty -- is ignored. That's contrary to normal UNIX usage; everything after the "--" should be interpreted as an argument rather than a flag.
July 05, 2008
On Sat, 05 Jul 2008 14:32:25 +0100, Christopher Wright <dhasenan@gmail.com> wrote:

> Lars Ivar Igesund wrote:
>> superdan wrote:
>>> then parse this using tango arguments please:
>>>
>>> ssh -v ls -la
>>>
>>> thanks.
>>  Everything until ls is easy (including the hostname which is required by
>> ssh), but it appears to ignore the -la part which I have noted to the
>> implementors. I believe I did say that although the requirments document (I
>> probably wrongly said design document) mandates that this should be
>> possible, the implementation and design is not fully reviewed yet and may
>> have bugs.
>>  The order is completely preserved and enforcable though.
>>
>
> What about "ssh -v -- ls -la", I wonder.
>
> Actually, I don't wonder. The documentation says that the empty -- is ignored. That's contrary to normal UNIX usage; everything after the "--" should be interpreted as an argument rather than a flag.

Documents (and requirements specs) can have bugs too.
July 05, 2008
Christopher Wright wrote:

> Lars Ivar Igesund wrote:
>> superdan wrote:
>>> then parse this using tango arguments please:
>>>
>>> ssh -v ls -la
>>>
>>> thanks.
>> 
>> Everything until ls is easy (including the hostname which is required by ssh), but it appears to ignore the -la part which I have noted to the implementors. I believe I did say that although the requirments document (I probably wrongly said design document) mandates that this should be possible, the implementation and design is not fully reviewed yet and may have bugs.
>> 
>> The order is completely preserved and enforcable though.
>> 
> 
> What about "ssh -v -- ls -la", I wonder.
> 
> Actually, I don't wonder. The documentation says that the empty -- is ignored. That's contrary to normal UNIX usage; everything after the "--" should be interpreted as an argument rather than a flag.

I agree that part should be available to the user.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
July 05, 2008
Lars Ivar Igesund Wrote:

> superdan wrote:
> 
> > Lars Ivar Igesund Wrote:
> > 
> >> superdan wrote:
> >> 
> >> > Lars Ivar Igesund Wrote:
> >> > 
> >> >> As for preserving and enforcing order, that was one of the design goals for this implementation and thus it should be considered a bug if not easily done.
> >> > 
> >> > put in layman's terms: making it unusable for applications that launch secondary commands was a design goal.
> >> 
> >> No.
> > 
> > then parse this using tango arguments please:
> > 
> > ssh -v ls -la
> > 
> > thanks.
> 
> Everything until ls is easy (including the hostname which is required by ssh), but it appears to ignore the -la part which I have noted to the implementors. I believe I did say that although the requirments document (I probably wrongly said design document) mandates that this should be possible, the implementation and design is not fully reviewed yet and may have bugs.
> 
> The order is completely preserved and enforcable though.

rats! i forgot the hostname indeed. ok let me fix:

ssh -v host ls -la

my question is, assuming all bugs are fixed, how does the code for parsing this look like with tango arguments?

to make things more interesting, let's use this example:

ssh -v host -v ls -la

everything before and after host but before command is an option for ssh. everything after command is passed to the command.

could you show how this is coded (assuming bugs are fixed) in both tango arguments apis. thanks.

here's my std.getopt implementation for the example. let's see how others fare.

void main(string[] args)
{
    auto offset = find!("a.length && a[0] == '-'")(args) - begin(args);
    enforce(offset != args.length, "Hostname not specified");
    auto host = args[offset];
    args = args[0 .. offset] ~ args[offset + 1 .. $];
    uint verbosityLevel;
    ............
    getopt(args,
        std.getopt.config.stopOnFirstNonOption,
        "v+", &verbosityLevel,
        ......... more stuff ......);
    if (args.length)
    {
        ........... start shell session on host .........
    }
    else
    {
        ........... run command on host ..........
    }
}

July 05, 2008
Nick Sabalausky Wrote:

> Consider yourself extremely lucky any of us have been trying to help you after putting up with your attitude. I haven't seen one post from you that didn't include unproductive and clearly deliberate sarcasm or insults. I know this newsgroup operates on an "assume good faith" approach, but even that only goes so far. Keep it up and even the most laid-back people's patience will wear thin. If this were like most forums I've been on you would have already been banned by now for being generally disruptive.

hey nick. been lookin' over the past messages and thinking for a bit. i need to apologize for layin' it too thick.

my problem was i delurked in a fuckshat-up mood due to some attitudes that've been goin' around this group for a while. some around here feel they can demand shit solely because they use d. there's a foul sense of democracy when everybody who's nobody has a proposal and self-righteously demands for an answer. also afaict walter is very connected with this group and listens. yarp he has no time to answer the good suggestions but you know he's listenin' and you can see that with each release.

plus it's like brain and mouth add to a constant sum around here. a hundred years from now sociologists will crack their skulls to figure this phenomenon on digitalmars.d. the less they know the more sure they are they know and the more they ask, boggles my mind. and makes me fuckshit.

the problem is my fuckshat-up mood carried without reason to normal discussions like getopt. looking back i'm amazed some people (such as yourself) could actually come forth and establish communication. says a lot about'em. and guess what. they tend to be the more knowledgeable too.
July 06, 2008
"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


July 06, 2008
"Nick Sabalausky" <a@a.a> wrote in message news:g4k93l$1mh$1@digitalmars.com...
>
> Command-line parsing is one of the big reasons I really wish D had C#/Java style attributes. I came across this one particular C# command-line parser (written by a Peter Hallam) a few years ago and absolutely fell in love with it, and by extention, attributes.

After all the responses, I'm now sufficiently convinced that there aren't any obvious cases where C#/Java-style attributes would allow for functionality that can't be achieved with D templates. However, I still think C#/Java-style attributes should be added to D for the following reasons:

1. Part of D's design philosophy (and one of the main reasons I've been so drawn to D) is that it gives the programmer all the tools they may need and leaves it up to the programmer to use whatever they feel is the best fit for the task at hand. We have all the standard OO features, but unlike C#/Java, you're not required to fit your designs into an OO model if you feel a procedural approach is more appropriate for what you're doing. We have garbage collection - but you can still manage memory manually if you need to or want to.

Using getopt or the Tango equivalent, you're processing command line args procedurally - the structure of the command line arguments is defined by the way you call the appropriate function(s)/template(s) and the parameters you pass into those function(s)/template(s). Using the C# attribute approach, that's flipped around: you're defining the structure of the arguments, and that structure drives the parsing.

Clearly, you can implement any command-line you want using either method. But if you're going to disallow the latter method just because you can get the same effect with the former method, then not only does that break an important part of D's design philosophy, but you may as well start throwing away things like "while", "for" and "foreach" as well. After all, any loop you can implement with those constructs can already be implemented with conditionals and gotos. So why do we include them? Because the programmer may decide they're a better fit for what they're trying to do.

2. Maybe it's just my inexperience with D templates, but it seems that any non-trivial template magic (ie anything beyond standard template functions and template classes) has a tendency to involve dynamically generating source code by pasting together various source code pieces and parts. Now that's fine. In fact, that makes D's templates extremely powerful and extremely useful. But it also makes that sort of template a very blunt, if not crude, instrument.

In fact it very much resembles writing text-book-example PHP code or classic-style ASP. And there are good reasons people are moving from PHP to Ruby on Rails, and from classic ASP to ASP.NET. Sure, pasting snippets of source code together is very powerful, but it also tends to get rather messy.

Of course, I'm not saying we should stop using fancy template trickery or other forms of automatic code generation. And I'm not saying any of those are any sorts of inherently bad things. But everything does have its pros and cons and if there's another way to achieve something you're after that doesn't use such a blunt tactic, then even if not everyone uses the alternative approach, having it that can only be a good thing.