On Wednesday, 17 September 2014 at 00:46:07 UTC, IgorStepanov
wrote:
Why not subj?
D allows annotate with UDA the most of named symbols.
There are three category of named symbols, which cannot be
annotated: module declarations, function arguments and enum
members.
Enum members are trivial symbols and annotation possibility for
them probably does not make sense.
However, annotation unpossibility for module declaration and
function arguments looks strange.
Why all this talk?
I've created pull request for dmd, which allows UDA for modules
(https://github.com/D-Programming-Language/dmd/pull/3947) and
Walter says that I should open topic in n.g. and justify the
usefulness of this enhancement.
I will give a few examples when UDA can be used for modules and
arguments:
First example: in ORM framework, like hibernate, I want to add
posibility to put the module in correspondence to DB scheme:
@Sheme("STOCK") module Stock;
@Entity("WAYBILLS") class Waybill //STOCK.WAYBILLS
{
....
}
@Entity("ITEMS") class Item //STOCK.ITEMS
{
....
}
***************************************************
The second example is a Web MVC framework
@BindModule("forum") module dlang.engine.controllers.forum;
@BindPath("/")
class MainController : AbstractController!(MainController)
{
@BindMethod("/newpost")
View newPost(Request req,
@BindParam("tid") int threadID,
@BindParam("author") string author,
@BindParam("subj") string subject,
@BindParam("msg") string message)
{
///
return new TemplateView(model,
"/dlang/templates/forum/newpost.tmpl");
}
}
***************************************************
The third example is a my runtime reflection implementation:
I've created generator which walking down the scope symbol, and
store runtime data, if symbol is annotated with a special UDA.
For example, if class Annotated with @reflect!all, generator
will save information about all class members into special
place. However, if local scope symbol is not annotated,
information about its members will not saved:
@reflect!all class Foo
{
int a;
class Bar
{
int b;
}
}
In this example, information for Foo will be saved (that Foo
contains "a" and class "Bar"), but information about Bar
members will not be saved.
Thus I want to be able to annotate module that the generator
will keep information about its members.
Destroy.
UDA's for enum members do make sense, especially in the case of
serialization, where you might want a member to be used in your
code as one thing, but parsed as a different name, for instance,
serializing code where the enum member would be a keyword in D.
