On 6 April 2012 13:12, Walter Bright <newshound2@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.