Custom attributes (again)

[Ary Manzana]

On 4/6/12 6:12 PM, Walter Bright wrote:
> On 4/6/2012 2:50 AM, Ary Manzana wrote:
>> The syntax in Java for declaring an attribute:
>>
>> public @interface Foo {
>> String xxx;
>> int yyy;
>> }
>>
>> In D maybe @interface could be used to (in order to avoid introducing
>> another
>> keyword... or maybe use @attribute instead):
>>
>> @attribute Foo {
>> string xxx;
>> int yyy;
>> }
>
> I don't see the need for creating a new kind of symbol.
>
>
>> 2. You use them by using their names. What you are proposing if for
>> attribute
>> foo to be @attr(foo). But in Java it's @foo.
>>
>> So in Java you would use that attribute like this:
>>
>> @Foo(xxx = "hello", yyy = 1);
>> void func() {}
>>
>> Then you can get the "Foo" attribute in func, and ask for it's xxx and
>> yyy.
>
> This is a runtime system.

Yes, but I'm thinking about a compile-time system (as I showed in the 
example usages below).

>
>
>> Now, your proposal is much simpler and it will become inconvenient in
>> some
>> cases. For example suppose you want to provide attributes for
>> serialization (I
>> guess the classic example). With your proposal it would be:
>>
>> /// This is actually an attribute. Use this together with
>> serialized_name.
>> enum serialize = 1;
>> enum serialized_name = 2;
>>
>> @attr(serialize = true, serialized_name = "Foo")
>> int x;
>
> No, it would be:
>
> enum serialize = true;
> enum serialize_name = "Foo";
> @attr(serialize, serialized_name) int x;
>
> There would be no initialization in the @attr syntax.

Hmmm... I didn't get that quite well. You are using the symbol's name as 
the attribute name? In my example I missed splitting it into two files:

my_attributes.d:

@attribute serialize { }

my_usage_of_it.d:

import my_attributes;

@serialize(...)


>
>> Now, with the way things are done in Java and C#:
>>
>> /// Marks a field to be serialized.
>> @attribute serialize {
>> /// The name to be used.
>> /// If not specified, the name of the member will be used instead.
>> string name;
>> }
>>
>> @serialize(name = "Foo")
>> int x;
>>
>> You can see the syntax is much cleaner. The attribute declaration also
>> serves as
>> documentation and to group attributes related to the serialization
>> process.
>
> I don't see that it is cleaner - there's no particular reason why a new
> symbol type needs to be introduced.
>
>>
>> Now, to implement this is not very much difficult than what you proposed.
>>
>> 1. Introduce the syntax to define attributes. Piece of cake, since
>> it's much
>> more or less the syntax of a struct, but functions or nested types are
>> not
>> allowed. Parse them into an AttributeDecl or something like that.
>> 2. When the compiler finds @attr(field = value) it uses normal lookup
>> rules to
>> find "attr". Then it checks it's an attributes. Then all fields are
>> check in
>> turn to see if their type match. You can probably put there anything
>> that's
>> compile-time evaluatable, though usually primitive types and strings
>> are enough.
>> If a field is not specified, it's type.init will be used.
>> 3. The syntax for querying is almost the same as you proposed:
>>
>> __traits(hasAttribute, x, serializable) // true
>> __traits(getAttribtue, x, serializable, name) // "Foo"
>>
>> 4. Declare the core attributes in object.di or similar: @safe,
>> @nothrow, etc.
>> You can also document them.
>> 5. Probably deprecate __traits(isSafe) and so on, since hasAttribute
>> can be used
>> for that.
>
> @safe, @nothrow, etc., require a lot of semantic support in the
> compiler. They cannot pretend to be user defined attributes.

Yes they can. That's how it is done in C# and Java. In fact, IUnknown is 
pretending to be an interface and has semantic support in the compiler.