Proposal: user defined attributes

[deadalnix]

Le 20/03/2012 16:17, Andrei Alexandrescu a écrit :
> On 3/20/12 12:50 AM, Kapps wrote:
>> On Monday, 19 March 2012 at 21:00:32 UTC, Andrei Alexandrescu wrote:
>>> On 3/19/12 3:55 PM, F i L wrote:
>>>> I think this could get tricky for the compiler to confidently use given
>>>> that the mixed in enums can collide with existing members (although not
>>>> likely). Also, if objects are not identified as being unique marked (in
>>>> the compilers eyes), what specific attribute post-fixes will it be
>>>> searching for on enums members?
>>>
>>> Not a big issue, the name could always contain a uuid which makes
>>> collision practically impossibile.
>>>
>>> Andrei
>>
>> And with parameters? Or how about run-time reflection, which is
>> something that should be added eventually for attributes as well (that
>> is, typeid(Blah).getCustomAttributes())? We can't manually add things
>> into the TypeInfo.
>
> Perhaps we should add a field of type Variant[string].
>
>> This is an already ridiculously hackish approach, and
>> it *does not* work for anything besides trivial applications. It is
>> completly unreasonable to expect everything to be done in a library; the
>> compiler exists for a reason and at some point you have to draw the
>> line.
>
> I'm afraid I disagree. A targeted language feature definitely makes a
> library approach inferior, by definition. But adding features is
> cheating, like printing money is for a government: very tempting, with
> apparently good short-term benefits, but with devastating cumulative
> effects.
>
> Also, as I mentioned, the availability of the easy escape hatch of
> adding a language feature thwarts creativity. Nobody will care to think
> about and come with idioms that use the language to do great things, if
> they know a language feature could be always added that makes things
> "nicer".
>
> I'm not saying this particular feature should or should not be in the
> language, but I wish our community exercised considerably more restraint
> when it comes about adding new language features.
>

That feature has been added to java with great benefit. I think the 
underlying need here is AOP. Adding annotation to java had great 
benefice in introducing AOP capabilities to the language.

See :
http://projectlombok.org/

Considering that D has great compile time capabilities, this is 
somewhere we want to go.

Additionnaly, this is something that remove other capabilities, and 
replace them by lib support. For example, with @synchronized, I could 
specify the phobos that I want that method or class to be synchronized, 
and the lib is able to add the needed code to ensure that functionality 
at compile time.

I have to say that the whole idea of attaching property to instance 
doesn't make any sense to me - Walter make a good point on that I think, 
so I will not repeat his arguments.