The future of UDAs.

[Gor Gyolchanyan]

I think I really don't know what exactly do the UDAs do at the moment,
judging from your reply.The only documentation was the original D.anounce
post of yours. Is there a way I can get a reliable documentation on this?

Use cases:

1. I have a declaration with a UDA struct. I introspect the types I need
and add their names to an array in that struct. read that struct in a
static constructor and do necessary stuff with all those types. Is this
possible currently?

2. I have some code, which must be run on any type, marked with a special
UDA. Can I have that code executed without explicitly having to mix stuff
in every module?

I guess the way UDAs were originally designed, they have absolutely nothing
to do with what I envisioned.




On Tue, Nov 27, 2012 at 3:11 PM, Walter Bright
<newshound2 at digitalmars.com>wrote:

> On 11/27/2012 6:42 PM, Gor Gyolchanyan wrote:
>
>> AFAIK, currently UDAs are set at declaration site, are immutable and the
>> declaration cannot get additional UDAs externally. Moreover, only global
>> declarations can have UDAs, which removes some very useful possible uses
>> of UDAs.
>>
>
> What very useful thing could be done with UDAs on local variables?
>
>
>
>  Lack of mutable compile-time variables sometimes cripples the
>> metaprogramming in D. For instance all classes, derived from a certain
>> type must be dealt with in a special way, which requires a tuple of
>> those types. Gathering a tuple of unrelated types is currently
>> impossible, because that would require mutable compile-time variables.
>>
>
> I don't understand this. It is perfectly possible to create compile time
> tuple of (int, long, float, int*, S).
>
>
>
>  Mutable compile-time variables would also be extremely useful for
>> implementing a very powerful compile-time reflection library without the
>> need for compiler magic. All you'd have to do is mix in a template in
>> your class or your module and voila. The mixin would then add the
>> introspected declarations to the central compile-time declaration
>> repository.
>>
>
> I don't understand the difficulty here. UDAs are additive, so you could
> mixin your template in one space at the top, and it will apply to all the
> declarations nested under it, exactly like other attributes do now.
>
>
>
>  There are also many cases when some actions need to happen in case a
>> declaration gets a UDA of a specific type. For instance, a powerful RTTI
>> library, which (when a type gets a dedicated RTTI-typed UDA) adds the
>> run-time information about the class to the central registry at
>> load-time.
>>
>
> That can be done now. Loop over the declarations, checking to see if each
> has a particular attribute.
>
>
>  This kind of stuff could be easily achieved using the
>> constructors and destructors of the structures, being added to the UDAs
>> of a declaration (in this case a class). The only missing thing for this
>> to work is the ability for the constructor to see the declaration it's
>> being put on. I'd personally expect there to be some sort of a
>> __traits(**getAttributeDeclaration), which would evaluate to the symbol
>> on
>> which the enclosing type (a structure, a union or whatever) is being
>> placed on as an attribute.
>>
>
> That could cause ugly forward reference issues, and also recall that a UDA
> can be applied to many declarations at once.
>
>


-- 
Bye,
Gor Gyolchanyan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20121127/743ea378/attachment.html>