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

[Nick Sabalausky]

"Nick Sabalausky" <a at a.a> wrote in message 
news:g4k93l$1mh$1 at 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.