Proposal: user defined attributes

deadalnix deadalnix at gmail.com
Tue Mar 20 14:36:56 PDT 2012


Le 16/03/2012 17:09, Andrei Alexandrescu a écrit :
> On 3/16/12 8:35 AM, Adam D. Ruppe wrote:
>> enum Serializable { yes, no }
>>
>> @note(Serializable.yes) int a;
> [...]
>> foreach(i, exp; __traits(getNotes, a)) {
>> static assert(is(typeof(exp) == Serializable);
>> static assert(exp == Serializable.yes);
>> }
>
> So we have:
>
> class A {
> @note(Serializable.yes) int a;
> ...
> }
>
> vs. a hypothetical in-language solution:
>
> class A {
> int a;
> mixin(note("a", Serializable.yes));
> ...
> }
>
> I wonder to what extent the in-language solution can be made to work.
>
>
> Andrei

It is more tricky if the property isn't a simple attribute to read. 
Again, consider what is done with this simple example : 
http://projectlombok.org/

We have the opportunity here to introduce in D the concept of aspect 
oriented programming. This is HUGE. If you are afraid of the addition of 
a functionnality to the language, don"t worry, you are not just adding a 
functionnality, but a whole new paradigm.

And, BTW, this would allow us to drop some functionalities that now can 
be provided by phobos (synchronized for example is an obvious one). Same 
goes for override, deprecated, and the fun thing is that we can 
implement our own to extends the language even more as lib.

Even the propagation of pure, @safe, nothrow and const that has been 
discussed recently can be done with that feature.

If you are worried about introducing language features (I am) you should 
definitively introduce that one, because lot of features has already 
been included just because that one is lacking.

Adding compile time information to a type is the visible part of the 
iceberg. Really.


More information about the Digitalmars-d mailing list