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

[Nick Sabalausky]

"Lutger" <lutger.blijdestijn at gmail.com> wrote in message 
news:g4ss8s$1gqg$1 at digitalmars.com...
> Nick Sabalausky wrote:
>
>> 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.
>
> I'm not sure attributes alone are generic and generally useful enough to
> support the argument that they enable a specific programming style.

I wasn't trying to say that attributes would be useful in all situations. 
Just that there are a lot of situations in which they would be useful enough 
to be a reasonable, athough not totally essential, alternative to templates.

Obviously it's not going to change the way you iterate over an array or 
anything like that. But going back to the command-line parsing example, 
suppose that you *want* to design it in a way where you define the 
command-line "language" by a class and use that to drive the parsing - 
instead of the other way around. Currently, the only way to do that in D, 
without giving up the ability to use special options that don't have a 
class-definition-equivalent (such as required/optional) would involve a 
template mixin that dynamically generates the class. But as soon as you do 
that, you lose the ability to actually look at or edit your class definition 
in the source file in the same way the you would look at or edit any other 
class.

On other words, there are situations, even though it's not all situations, 
where attributes would allow you to implement certain types of functionality 
that could otherwise only be achieved by hiding chunks of your code behind 
source-generating template mixin voodoo (which I currently find myself 
making enormous use of). Of course, one could counter that with, "But why 
not just use the source-generating template mixins?" - to which I could 
counter "Why would you want a while loop? Just use for. But why desire a for 
loop? Just use goto. Etc..." You don't *have* to. But some people have 
reasons why they prefer it.

> But
> perhaps reflection / introspection is, and attributes as far as I
> understand them are part of C#'s reflective capabilities, which are way
> more powerful than what D has.
>

I admit I'm uncertain whether proper attribute support would require 
run-time reflection, or if compile-time would be sufficient. Though I'm 
still for the addition of runtime reflection in either case (*in addition* 
to compile-time, of course... See explanation below).

> However, the limited reflective power of D is at least partly intentional
> though it seems to be growing. I recall these motivations:
> - Lots of reflection bloats object code
> - D has and will have some more compile time reflection (templates,
> __traits, is-expressions, etc.)
> - In many cases, compile time reflection is a sufficient replacement for
> runtime reflection
> - In other cases reflective capabilities that are lacking can be built
> using compile time reflection
>

D's compile-time approach to reflection has indeed impressed me because of 
the level of functionality it allows at such better performance than runtime 
reflection. As far as I'm aware, every other language that has reflection 
doesn't support any such compile-time version of it. In that respect, I'm 
more impressed with D's reflection than I am with say, C#'s reflection.

However, now that we have that compile-time reflection in place, I see no 
design reason (there may very well be certain technical or syntactic hurdles 
for all I know) to not add run-time reflection. In fact, the way I see it, 
it would be against D philosophy not to (Give the programmer the tools they 
may need, and let them choose what's appropriate for their task).