April 06, 2012 Re: Custom attributes (again) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ary Manzana | 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 Re: Custom attributes (again) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kapps | 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 Re: Custom attributes (again) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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 Re: Custom attributes (again) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 Re: Custom attributes (again) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 Re: Custom attributes (again) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 Re: Custom attributes (again) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 Re: Custom attributes (again) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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 Re: Custom attributes (again) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ary Manzana | 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 Re: Custom attributes (again) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
Copyright © 1999-2021 by the D Language Foundation