Why D Needs Attributes (Was: Command-line arguments)

[Nick Sabalausky]

 "superdan" <super at dan.org> wrote in message 
news:g4lcjp$2dg9$1 at digitalmars.com...
> Nick Sabalausky Wrote:
>>
>> The getopt version forces you to list each variable three times. Once for
>> the variable itself, once more to tell getopt what it's called, and a 
>> third
>> time to tell getopt where it is. That's highly redundant. They're only
>> listed once for the C# version.
>
> narp. getopt is better for 2 reasons. first, if i want to have an option 
> with a dash in it, with getopt you say;
>
> bool showControlChars;
> getopt(args, "show-control-chars", &showControlChars);
>
> i and you and anyone who's used getopt once knows how to do that. but i 
> have no idea how to do that in c#. there may be some shitty attribute to 
> do so but i have to go check the manual. who wins?
>

The C# one could be easily modified to use a dash-based convention. Flip a 
switch, it's dash-based, flip it back, it's camel-cased. If for some bizarre 
reason you wanted an inconsistent style, that could be done too - and you'd 
only have to specify it for the deviating cases. Obviously that can be done 
in D, but I'm saying that the C# approach is perfectly capable of the same 
thing as well.

But at this point you're really just splitting hairs anyway. My main point 
was simply that attributes allow for fewer tradeoffs between DRY-ness and 
power. Command line parsers are good illustrative examples of that. 
Although, as Lutger pointed out, D's vastly superior template system does 
help compensate for the lack of attributes.

> second, yarp i do define the var and then specify it in the getopt thing. 
> but that's a good thing, gives me freedom. i can put it locally, or at 
> module level, or in another object. but in c# it's always a member of a 
> new type. shit. i have to define a freakin' *type*. that's useless 
> baggage. why do i have to define a type to parse my command line shit. 
> thanks but i'll use getopt.
>

Tossing related variables all over the place just because you don't feel 
like making one extra class smacks of laziness. Sure, that can work fine for 
trivial programs, but the first time you work on anything substantial (tens 
of thousands of lines of code), you'll quickly see it blow up in your face. 
Running away from modularization is just bad design.

>> (The getopt version could probably be
>> changed to extract the name from the variable using templates and traits
>> though, and it could probably eliminate the rest of that redundancy by
>> sticking the vars into a class or stuct, but then it would lose the 
>> ability
>> to let you specify options for each var. Attributes would bring that 
>> ability
>> back without creating reduncancy).
>
> run ls --help. you'll see there are 18 options with dashes in'em and 23 
> without. that's like 40/60.
>
> but then maybe some-option-x could be converted automatically to 
> someOptionX by a template. heh we have an enhancement idea right there.
>
>> Regarding the C# version:
>> - Sticking the variable declarations inside a class is trivial.
>
> yarp but i have to have a class in the first place.
>

You're already declaring the variables you need in the first place. May as 
well just put them in the same place (basic good design anyway), and stick 
"class xx {}" around it. Takes all of about ten seconds. And if you're too 
impatient to take few extra seconds up-front, or even a few extra minutes 
(development time, not runtime, of course), then you're in the wrong field.

>> - All of the stuff in square brackets (attributes) are optional.
>> (If you do specify any attributes, then the AttributeType is required,
>> however I was able to remove that restriction in about two minutes by 
>> adding
>> two trivial constructors.)
>
> two minutes for command line shit is two minutes too many. that's the 
> problem. command line is easy shit. should be a !brainer. everybody doing 
> command line shit asks me to waste time with their crappy api. getopt in 
> phobos is the first ever to ask me to be done with it in seconds and move 
> on. i think it makes it look so simple people don't see what a work of art 
> it is.
>

A lot of people here do consider it a work of art. I don't though, because 
it creates a bunch of redundancies. As I've pointed out though, I'm not 
saying those redundancies couldn't be eliminated. If and when that does 
happen, I'd certainly praise it for being slick enough to pull off the power 
and DRY-ness of the attribute-based approach without actually using 
attributes. However, whether I would end up considering templates or 
attributes to necessarily be a better fit for the particular problem, I 
really can't say.

>> - You can specify a custom help string for each element.
>
> guess this could be improved in getopt:
>
> uint shits;
> getopt(args,
> "shits number of shits given for this run", &shits);
>
> so then the space separates the option from the help string.
>

I wasn't saying getopt couldn't do that. I was responding to this: "...the 
no-good generated help string that always is too short and uninformative to 
help shit." If my response wasn't relevant to that statement, then it's 
because your original post wasn't very clear. Lots of whining and cussing, 
not much content or coherency.

>> - The fact that there could be multiple files *IS* inferred by using an
>> array of strings. (At least if you don't use any attributes, that is. But
>> that can be fixed fairly easily too.)
>
> hum. so then why would the attributes be needed in the first place.

1. For all of the other attribute options besides that one. 2. In this 
particular case, the important thing is not whether or not it takes multiple 
inputs. The important thing is the distinction between "Multiple" and 
"MultipleUnique". Ie, whether or not ["fileA", "fileB", "fileA"] is allowed.

>
>> If anyone's interested, I found a link:
>> http://www.codeplex.com/CommandLineArguments
>
> sorry won't read. :)
>

That wasn't directed at you. I had a feeling you wouldn't be interested ;)