Le 05/04/2012 20:51, Walter Bright a écrit :
> On 4/5/2012 11:32 AM, Timon Gehr wrote:
>> Ideally it would be powerful enough to allow changing the type, but most
>> applications probably want the type to stay the same.
>
> Having it perturb the type implies a huge swamp of how that affects the
> semantics. You've got overloading, name mangling, type inference,
> implicit conversions, covariance, etc.
>
> All I can say is I see no way that can work with user defined semantics.

I did some hacking into dmd in that regard, and I can confirm this is pretty hard. The problem is already quite hard, but the lack of separation of concerns into dmd's ast make things even harder.

I'm afraid we have to delay anything that do codeception in a first shot, which is really sad because this is promising. I still think this is somewhere we have to go at some point, but we will have to wait.

On 2012-04-05 14:00, Manu wrote:
> I just want to add more real-world experience to the controversy.
> I'm finding myself needing to use custom attributes almost every day.
>
> I have numerous systems that need to scan the module for things marked
> accordingly to automate bindings to their respective systems.

Yes, give us custom attributes now :)

-- 
/Jacob Carlborg

On 2012-04-05 19:35, Walter Bright wrote:
> On 4/5/2012 5:00 AM, Manu wrote:
>> C# and Java both have attributes, following these established design
>> patterns, I
>> don't think there should be any mystery over how they should be
>> implemented.
>
> At the Lang.NEXT conference over the last 3 days, I was able to talk to
> many smart people about attributes. But I did find some confusion - are
> they best attached to the variable/function (i.e. "storage class"), or
> attached to the type ("type constructor")? I think the former. Attaching
> it to the type leads to all sorts of semantic issues.
>
>  From your list of uses, it looks like attaching it to the variable or
> function is an apropos solution.

If I recall correctly, both Java annotations and C# attributes let you specify with a fine grained control on what the attributes are attached to.

@foo FooBar bar () {}

For example, is "@foo" attached to "FooBar" or "bar". Java uses the @Target annotation to specify this.

-- 
/Jacob Carlborg

On 05-04-2012 22:06, Jacob Carlborg wrote:
> On 2012-04-05 19:35, Walter Bright wrote:
>> On 4/5/2012 5:00 AM, Manu wrote:
>>> C# and Java both have attributes, following these established design
>>> patterns, I
>>> don't think there should be any mystery over how they should be
>>> implemented.
>>
>> At the Lang.NEXT conference over the last 3 days, I was able to talk to
>> many smart people about attributes. But I did find some confusion - are
>> they best attached to the variable/function (i.e. "storage class"), or
>> attached to the type ("type constructor")? I think the former. Attaching
>> it to the type leads to all sorts of semantic issues.
>>
>> From your list of uses, it looks like attaching it to the variable or
>> function is an apropos solution.
>
> If I recall correctly, both Java annotations and C# attributes let you
> specify with a fine grained control on what the attributes are attached to.
>
> @foo FooBar bar () {}
>
> For example, is "@foo" attached to "FooBar" or "bar". Java uses the
> @Target annotation to specify this.
>

C#'s grammar directly encodes what metadata element the attribute is attached to. How feasible this is with D's rather... loose attribute/modifier parsing, I don't know.

-- 
- Alex

Le 05/04/2012 22:06, Jacob Carlborg a écrit :
> On 2012-04-05 19:35, Walter Bright wrote:
>> On 4/5/2012 5:00 AM, Manu wrote:
>>> C# and Java both have attributes, following these established design
>>> patterns, I
>>> don't think there should be any mystery over how they should be
>>> implemented.
>>
>> At the Lang.NEXT conference over the last 3 days, I was able to talk to
>> many smart people about attributes. But I did find some confusion - are
>> they best attached to the variable/function (i.e. "storage class"), or
>> attached to the type ("type constructor")? I think the former. Attaching
>> it to the type leads to all sorts of semantic issues.
>>
>> From your list of uses, it looks like attaching it to the variable or
>> function is an apropos solution.
>
> If I recall correctly, both Java annotations and C# attributes let you
> specify with a fine grained control on what the attributes are attached to.
>
> @foo FooBar bar () {}
>
> For example, is "@foo" attached to "FooBar" or "bar". Java uses the
> @Target annotation to specify this.
>

This is bar's declaration.

On Thursday, 5 April 2012 at 17:36:31 UTC, Walter Bright wrote:
> On 4/5/2012 5:00 AM, Manu wrote:
>> C# and Java both have attributes, following these established design patterns, I
>> don't think there should be any mystery over how they should be implemented.
>
> At the Lang.NEXT conference over the last 3 days, I was able to talk to many smart people about attributes. But I did find some confusion - are they best attached to the variable/function (i.e. "storage class"), or attached to the type ("type constructor")? I think the former. Attaching it to the type leads to all sorts of semantic issues.
>
> From your list of uses, it looks like attaching it to the variable or function is an apropos solution.

I'm not sure if I'm understanding this correctly, but by attaching to the type do you mean altering the type of the declaration such as shared or const do? If so, I am completely against attributes being able to do this; there's already better ways such as a struct with alias this. Another issue is that if runtime reflection gets added, it would be nice to be able to add attributes at runtime. This could cause things to break if the type itself is changed instead of getting attached to the declaration. Plus, attributes should not be invasive, they're just notes.

The two main situations where I see attributes being used are:
1) Add some information about a declaration, such as @NotSerialized on a field.
2) Add some information to a type, such as @Serializable.
If this can be done, with being able to pass compile-time value(s) to the attribute, all situations I have ever desired/seen/used attributes for would work nicely.

On 4/6/2012 4:43 AM, Jacob Carlborg wrote:
> On 2012-04-05 14:00, Manu wrote:
>> I just want to add more real-world experience to the controversy.
>> I'm finding myself needing to use custom attributes almost every day.
>>
>> I have numerous systems that need to scan the module for things marked
>> accordingly to automate bindings to their respective systems.
>
> Yes, give us custom attributes now :)
>
Pretty please.

On 4/6/12 1:35 AM, Walter Bright wrote:
> On 4/5/2012 5:00 AM, Manu wrote:
>> C# and Java both have attributes, following these established design
>> patterns, I
>> don't think there should be any mystery over how they should be
>> implemented.
>
> At the Lang.NEXT conference over the last 3 days, I was able to talk to
> many smart people about attributes. But I did find some confusion - are
> they best attached to the variable/function (i.e. "storage class"), or
> attached to the type ("type constructor")? I think the former. Attaching
> it to the type leads to all sorts of semantic issues.

I don't understand the difference between "storage class" and "type constructor". I guess I do. But my answer is the same as deadalnix: they are attached to declarations (at compile time).

Can you give us an example of the confusion that arose? I can't understand it without examples.

I think it should work like this:

@custom
class Foo {

  @ custom
  void bar() { }

  void baz() { }
}

class Other {}

__traits(hasAttribute, Foo, 'custom') --> true
__traits(hasAttribute, Other, 'custom') --> false

// I have no idea how to iterate the members of Foo, or get a reference to the "bar" method... I can't understand what __traits(getMember) returns from the docs...

On 4/5/2012 5:00 AM, Manu wrote:
> C# and Java both have attributes, following these established design patterns, I
> don't think there should be any mystery over how they should be implemented.

I was thinking of something along the lines of what has been proposed here earlier:

  @attr(identifier = expression)

as a storage class, like:

  @attr(foo = bar + 1) int x;

and then:

  __traits(hasAttribute, x, foo)

would return true, and:

  __traits(getAttribute, x, foo)

would return the expression (bar+1). The expression would be compile-time only, evaluated at the point of declaration.

The implementation is simple enough, just attach to each symbol an array of (identifier,expression) pairs.

You could also omit the expression, and just have:

  @attr(bar) int y;

On Friday, 6 April 2012 at 06:47:56 UTC, Walter Bright wrote:
> On 4/5/2012 5:00 AM, Manu wrote:
> > C# and Java both have attributes, following these established
> design patterns, I
> > don't think there should be any mystery over how they should
> be implemented.
>
> I was thinking of something along the lines of what has been proposed here earlier:
>
>   @attr(identifier = expression)
>
> as a storage class, like:
>
>   @attr(foo = bar + 1) int x;
>
> and then:
>
>   __traits(hasAttribute, x, foo)
>
> would return true, and:
>
>   __traits(getAttribute, x, foo)
>
> would return the expression (bar+1). The expression would be compile-time only, evaluated at the point of declaration.
>
> The implementation is simple enough, just attach to each symbol an array of (identifier,expression) pairs.
>
> You could also omit the expression, and just have:
>
>   @attr(bar) int y;

I like it for the most part. One thing I'd like to see is placing multiple attributes both by using multiple @attr()'s, and by using comma separated identifier/expression pairs inside a single @attr. In other words, the following two declarations would be identical.

@attr(Description = "Blah", ReadOnly)
int ID;

@attr(Description = "Blah")
@attr(ReadOnly)
int ID;

My only concerns:

First, @attr() is a little verbose / not exactly pretty. This isn't really a big issue, since attributes aren't exactly piled on and it makes it easy to tell what's going on. It is a little uglier than in other languages however.

Secondly, from what I can tell it's an arbitrary key value combo. What would happen if you're working on a larger project and two unrelated libraries try to use the same attribute name to mean different things? With the module system this issue doesn't exist since you have to import it and can selectively/privately do so, but from what I understand the method you're proposing doesn't declare the attribute itself at all. Am I just misunderstanding this part?