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. 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.

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

"Lutger" <lutger.blijdestijn@gmail.com> wrote in message news:g4ss8s$1gqg$1@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).

Nick Sabalausky Wrote:
> 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.

http://thedailywtf.com/Comments/22-The-Offshore-Coordinator.aspx?CommentReplies=202585

Nick Sabalausky wrote:
<snip>talk about attributes</snip>

IMO and I'm not an expert on this - attributes by themselves are pretty
much worthless. however, if you combine them with additional tools they
become a very powerful feature.
If you have AST macros and reflection (both compile/run -time) than it's
far superior to just templates.
examples of some things that can be accomplished with that tool set:
- DBC (instead of putting it in the language [and not implementing it])
- Active objects and concurrency.
- Aspect oriented programming
- etc...