View mode: basic / threaded / horizontal-split · Log in · Help
July 05, 2008
Re: Why D Needs Attributes (Was: Command-line arguments)
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
Re: Why D Needs Attributes (Was: Command-line arguments)
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
Re: Command-line arguments
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
Re: Command-line arguments
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
Re: Command-line arguments
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
Re: Command-line arguments
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
Re: Command-line arguments
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
Re: Why D Needs Attributes (Was: Command-line arguments)
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
Re: Command-line arguments
"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
Re: Why D Needs Attributes (Was: Command-line arguments)
"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.
1 2 3 4 5
Top | Discussion index | About this forum | D home