View mode: basic / threaded / horizontal-split · Log in · Help
November 07, 2012
Re: User Defined Attributes
On 2012-11-07 21:41, Walter Bright wrote:

> Just functions? I thought one big use of UDAs was to mark classes as
> "serializable".

Exactly, the more we can annotated the better :)

-- 
/Jacob Carlborg
November 07, 2012
Re: User Defined Attributes
On 2012-11-07 21:38, deadalnix wrote:

>> Adding a whole new aggregate type is a pretty intrusive and major change.

Is it? Just have it behave as a struct or class. But I guess the 
suggestion below is just as good.

> So let's defined in object.d the following :
>
> @attribute struct attribute {}
>
> And then mark as @attribute anything that may used as attribute.
>
> @attribute struct foo {
>      string name;
> }
>
> @foo("asd") int a;
>
> If wasn't marked as @attribute, it wouldn't be an valid attribute.

I would be happy with this approach as well. But how much difference 
would it actually be to have:

attribute foo {
    string name;
}

-- 
/Jacob Carlborg
November 07, 2012
Re: User Defined Attributes
First of all: Awesome.

Secondly: Fastest-growing thread ever? ;)
November 07, 2012
Re: User Defined Attributes
On Wednesday, November 07, 2012 16:45:20 Nick Sabalausky wrote:
> First of all: Awesome.
> 
> Secondly: Fastest-growing thread ever? ;)

In Announce? Probably. In all of the D groups? Probably not. There have been 
some _very_ active threads in the main newsgroup. This thread is quite tame in 
comparison to a number of them. It _is_ very active though.

- Jonathan M Davis
November 07, 2012
Re: User Defined Attributes
On 11/7/2012 3:05 AM, Leandro Lucarella wrote:
> OK, that's another thing. And maybe a reason for listening to people having
> more experience with UDAs than you.
>
> For me the analogy with Exceptions is pretty good. The issues an conveniences
> of throwing anything or annotating a symbol with anything instead of just
> type are pretty much the same. I only see functions making sense to be accepted
> as annotations too (that's what Python do with annotations, @annotation symbol
> is the same as symbol = annotation(symbol), but is quite a different language).

There's another aspect to this.

D's UDAs are a purely compile time system, attaching arbitrary metadata to 
specific symbols. The other UDA systems I'm aware of appear to be runtime systems.

This implies the use cases will be different - how, I don't really know. But I 
don't know of any other compile time UDA system. Experience with runtime systems 
may not be as applicable.

Another interesting data point is CTFE. C++11 has CTFE, but it was deliberately 
crippled and burdened with "constexpr". From what I read, this was out of fear 
that it would turn out to be an overused and overabused feature. Of course, this 
turned out to be a large error.

One last thing. Sure, string attributes can (and surely would be) used for 
different purposes in different libraries. The presumption is that this would 
cause a conflict. But would it? There are two aspects to a UDA - the attribute 
itself, and the symbol it is attached to. In order to get the UDA for a symbol, 
one has to look up the symbol. There isn't a global repository of symbols in D. 
You'd have to say "I want to look in module X for symbols." Why would you look 
in module X for an attribute that you have no reason to believe applies to 
symbols from X? How would an attribute for module X's symbols leak out of X on 
their own?

It's not quite analogous to exceptions, because arbitrary exceptions thrown from 
module X can flow through your code even though you have no idea module X even 
exists.
November 07, 2012
Re: User Defined Attributes
On 11/7/2012 1:45 PM, Nick Sabalausky wrote:
> First of all: Awesome.
>
> Secondly: Fastest-growing thread ever? ;)


The historical UDA threads have been large, too.
November 07, 2012
Re: User Defined Attributes
Le 07/11/2012 23:20, Walter Bright a écrit :
> On 11/7/2012 3:05 AM, Leandro Lucarella wrote:
>> OK, that's another thing. And maybe a reason for listening to people
>> having
>> more experience with UDAs than you.
>>
>> For me the analogy with Exceptions is pretty good. The issues an
>> conveniences
>> of throwing anything or annotating a symbol with anything instead of just
>> type are pretty much the same. I only see functions making sense to be
>> accepted
>> as annotations too (that's what Python do with annotations,
>> @annotation symbol
>> is the same as symbol = annotation(symbol), but is quite a different
>> language).
>
> There's another aspect to this.
>
> D's UDAs are a purely compile time system, attaching arbitrary metadata
> to specific symbols. The other UDA systems I'm aware of appear to be
> runtime systems.
>
> This implies the use cases will be different - how, I don't really know.
> But I don't know of any other compile time UDA system. Experience with
> runtime systems may not be as applicable.
>

Java is mostly compile time (and optionally runtime). See 
http://projectlombok.org/ for what can be done at compile time with 
attributes + compiler hooks.

> Another interesting data point is CTFE. C++11 has CTFE, but it was
> deliberately crippled and burdened with "constexpr". From what I read,
> this was out of fear that it would turn out to be an overused and
> overabused feature. Of course, this turned out to be a large error.
>
> One last thing. Sure, string attributes can (and surely would be) used
> for different purposes in different libraries. The presumption is that
> this would cause a conflict. But would it? There are two aspects to a
> UDA - the attribute itself, and the symbol it is attached to. In order
> to get the UDA for a symbol, one has to look up the symbol. There isn't
> a global repository of symbols in D. You'd have to say "I want to look
> in module X for symbols." Why would you look in module X for an
> attribute that you have no reason to believe applies to symbols from X?
> How would an attribute for module X's symbols leak out of X on their own?
>
> It's not quite analogous to exceptions, because arbitrary exceptions
> thrown from module X can flow through your code even though you have no
> idea module X even exists.
>
November 07, 2012
Re: User Defined Attributes
Awesome. Lack of UDA has really caused some very ugly workarounds 
in my code, and it's really nice to see that it's being solved 
now. Probably one of the most important missing features I've 
encountered.

I do agree however with preventing any built-in types / literals 
being used as an annotation. It's just not safe, completely goes 
around the module system, and is abused in the same way as it 
would be with C++ exceptions. In C# for example, all attributes 
are classes derived from Attribute. This makes things a bit more 
obvious, allows a common base type (probably not needed in D 
because it's done at compile-time), but is rather hackish in my 
opinion (plus, in D you may want structs as attributes?). I 
definitely would like to see something like the @attribute 
suggestion though. Using types not meant to be used as attributes 
as attributes is dangerous and leads to conflicts when people 
want it to mean different things. What does '@Vector3f(1, 1, 1) 
int a' even mean? What if people use it to mean different things? 
It's just as confusing as '@3 int a'.
November 07, 2012
Re: User Defined Attributes
On 11/7/2012 2:40 PM, deadalnix wrote:
> Java is mostly compile time (and optionally runtime). See
> http://projectlombok.org/ for what can be done at compile time with attributes +
> compiler hooks.

Doesn't putting compiler hooks in for them make them inherently global?
November 07, 2012
Re: User Defined Attributes
started a new thread on this over in digitalmars.D
14 15 16 17 18 19 20 21 22
Top | Discussion index | About this forum | D home