On 6 April 2012 13:12, Walter Bright <newshou...@digitalmars.com> 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.
I don't think it's necessary to declare the struct as @attribute
explicitly, the '@' can easily imply the usage all on its own in the
declaration. The struct would remain a perfectly normal struct, and will be
useful if you want to get a struct somewhere in the code to inspect details
about the attribute.
@SomeStruct(blah) int x;
..
SomeStruct s = __traits(getAttribute, SomeStruct, x);
... do some stuff with the information that x was attributed
static if(s.thing == ??)
> 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.
It doesn't need to be runtime. The syntax works perfectly at compile time?
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.
Please don't. We've gone from a minor case of bracket spam now to a whole
bunch of extra lines for every single member, and you've also removed the
tight syntactical connection of the values from their attribute declaration
(one of the most important details, its safety, when people update/edit
classes). This is fast approaching the disconnected enum table which is the
whole thing we're trying to avoid.
There's also a namespace/scope problem here. 2 different systems from 2
different libraries will almost certainly use the 'serialise' attribute.
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.
See my point above, I don't think there's any need for a new symbol type...
The compiler would just keep a little table of attributes alongside
declarations, which you can query if you want to.
