April 06, 2012
On 2012-04-06 05:30, Ary Manzana wrote:

> 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...

I would like to have the possibility to attach attributes to types and parameters as well. Some think like this:

class Bar
{
    @not_null(Foo) bar (@custom int a) {}
}

Where @not_null is attached to "Foo" and @custom is attached to "a".

-- 
/Jacob Carlborg
April 06, 2012
On 2012-04-06 09:17, Kapps wrote:

> 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?

The way I'm thinking of attributes is that they are declared, somehow, in a module. Since it's declared in a module it would have the same rules any other declared symbol, with the possibility to use a fully qualified name.

-- 
/Jacob Carlborg
April 06, 2012
On 04/06/2012 02:23 PM, Jacob Carlborg wrote:
> I would like to have the possibility to attach attributes to types and
> parameters as well. Some think like this:
>
> class Bar
> {
> @not_null(Foo) bar (@custom int a) {}
> }
>
> Where @not_null is attached to "Foo" and @custom is attached to "a".
>

@not_null cannot be attached to "Foo". It would have to create a new symbol @not_null(Foo). And then, all the concerns Walter has raised apply.
April 06, 2012
On 2012-04-06 08:47, 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'm not a particular fan of that syntax. I would go with:

@identifier(key = value/expression)

Like:

@foo(k1 = bar + 1, k2 = bar + 2) int x;

If the attribute takes one key-value pair:

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

Can be shortened like:

@foo(bar + 1) int x;

And for attributes that don't take any values:

@foo int x;

-- 
/Jacob Carlborg
April 06, 2012
On 2012-04-06 09:32, Walter Bright wrote:
> Could do:
>
> [[name = value]]
>
> I suppose. Not sure what's better.

No. See my other reply.

-- 
/Jacob Carlborg
April 06, 2012
On 2012-04-06 09:47, Walter Bright wrote:
> On 4/6/2012 12:42 AM, Alex Rønne Petersen wrote:
>> Also, by storage class do you mean it will work only on fields?
>
> No. Storage classes work on fields, functions, and variables.
>

They need to be attachable to classes, structs, enums and so on as well.

-- 
/Jacob Carlborg
April 06, 2012
On 2012-04-06 09:48, Walter Bright wrote:
> On 4/6/2012 12:35 AM, Alex Rønne Petersen wrote:
>> It actually can be a problem. In .NET land, there are many attributes
>> across
>> many projects (and even in the framework itself) with the same names.
>> It turns
>> out that regular namespace lookup rules alleviate this problem.
>
>
> Perhaps a better scheme is:
>
> enum foo = 3;
>
> ...
>
> @attr(foo) int x;
>
> That way, foo will follow all the usual rules.
>

What would "3" do in this case? Be the value of the attribute?

-- 
/Jacob Carlborg
April 06, 2012
Jacob Carlborg wrote:
> I would like to have the possibility to attach attributes to types and
> parameters as well. Some think like this:
>
> class Bar
> {
> @not_null(Foo) bar (@custom int a) {}
> }
>
> Where @not_null is attached to "Foo" and @custom is attached to "a".

Do you mean return type? I think your syntax has some serious disadvantages. Consider parameters and multiple attributes.

For return types I'd like to see something like this:

@return: not_null
@return: MyAttr("foo")
Foo bar(@custom int a) {}

This is similar to C#'s [return: MyAttr]. Alternatively it might be:

@return(not_null)
@return(MyAttr("foo"))
April 06, 2012
On 2012-04-06 11:50, Ary Manzana wrote:
> On 4/6/12 3:48 PM, Walter Bright wrote:
>> On 4/6/2012 12:35 AM, Alex Rønne Petersen wrote:
>>> It actually can be a problem. In .NET land, there are many attributes
>>> across
>>> many projects (and even in the framework itself) with the same names.
>>> It turns
>>> out that regular namespace lookup rules alleviate this problem.
>>
>>
>> Perhaps a better scheme is:
>>
>> enum foo = 3;
>>
>> ...
>>
>> @attr(foo) int x;
>>
>> That way, foo will follow all the usual rules.
>
> At least in .Net and Java it's something like this.
>
> 1. You declare your attributes. This is something good, because you have
> a place to say "This attribute is used for marking fields as
> non-serializable".


This is much better, as I've said before.

-- 
/Jacob Carlborg
April 06, 2012
On 2012-04-06 12:12, Walter Bright wrote:

> I don't see the need for creating a new kind of symbol.

If you create a new symbol, i.e. "Foo" then it would obey the normal look up rules.


> This is a runtime system.

Says who? It doesn't need to be in D.

> I don't see that it is cleaner - there's no particular reason why a new
> symbol type needs to be introduced.

For attributes with a single value this syntax sugar can be allowed (and is in Java):

@serialize("Foo") int x;

I think that is clean.


-- 
/Jacob Carlborg