Source code annotations alla Java

[Jay Norwood]

On Friday, 21 January 2011 at 20:50:39 UTC, Jonathan M Davis 
wrote:
> On Friday, January 21, 2011 12:36:23 Ary Manzana wrote:
>> On 1/20/11 5:48 PM, Jacob Carlborg wrote:
>> > On 2011-01-20 21:34, Steven Schveighoffer wrote:
>> >> On Thu, 20 Jan 2011 15:03:55 -0500, Jacob Carlborg 
>> >> <doob at me.com> wrote:
>> >>> On 2011-01-20 19:18, Steven Schveighoffer wrote:
>> >>>> On Thu, 20 Jan 2011 13:07:58 -0500, Jacob Carlborg 
>> >>>> <doob at me.com> wrote:
>> >>>>> On 2011-01-20 15:02, Steven Schveighoffer wrote:
>> >>>>>> On Thu, 20 Jan 2011 08:47:28 -0500, Justin Johansson 
>> >>>>>> <jj at nospam.com>
>> >>>>>> 
>> >>>>>> wrote:
>> >>>>>>> Not long ago the Java Language people introduced the 
>> >>>>>>> idea of
>> >>>>>>> annotations together with an annotation processing 
>> >>>>>>> tool (apt).
>> >>>>>>> 
>> >>>>>>> Now perhaps the idea of source code annotations is not 
>> >>>>>>> actually a
>> >>>>>>> Java
>> >>>>>>> invention per se, however for someone learning D is 
>> >>>>>>> there any
>> >>>>>>> equivalent idiom [of Java annotations] in the D 
>> >>>>>>> language?
>> >>>>>> 
>> >>>>>> Haven't used Java since they added annotations, but I 
>> >>>>>> think they are
>> >>>>>> like C# attributes?
>> >>>>>> 
>> >>>>>> In any case, D has an annotation syntax like:
>> >>>>>> 
>> >>>>>> @property
>> >>>>>> 
>> >>>>>> But I think at the moment, annotations have no custom 
>> >>>>>> ability. Only
>> >>>>>> compiler-defined annotations are allowed. This may 
>> >>>>>> change in the
>> >>>>>> future,
>> >>>>>> but probably not short-term. FWIW, I think we need a 
>> >>>>>> much richer
>> >>>>>> runtime-reflection capability before we can use custom 
>> >>>>>> annotations
>> >>>>>> to any great effect.
>> >>>>>> 
>> >>>>>> -Steve
>> >>>>> 
>> >>>>> I would rather formulate it like: currently D has a 
>> >>>>> syntax for
>> >>>>> keywords that are similar to Java annotations.
>> >>>> 
>> >>>> I don't think it's the same thing. Keywords are not 
>> >>>> allowed to be used
>> >>>> anywhere else, even for things that would parse properly 
>> >>>> were they not
>> >>>> keywords. They are anchors for the parser to determine 
>> >>>> where it is. In
>> >>>> contrast, a compiler-defined annotation is parsed just 
>> >>>> the same as a
>> >>>> custom one, it's just that the meaning is predefined.
>> >>>> 
>> >>>> For example, you can legally do:
>> >>>> 
>> >>>> int property;
>> >>>> 
>> >>>> without error, but this won't even get past the parsing 
>> >>>> stage:
>> >>>> 
>> >>>> int struct;
>> >>>> 
>> >>>> -Steve
>> >>> 
>> >>> I assume you meant "int @property;"?
>> >> 
>> >> No. I meant int property;
>> > 
>> > Of course that would work, isn't that like saying this won't 
>> > work:
>> > 
>> > int struct_; // ?
>> > 
>> >> A keyword is specifically not allowed where the grammar 
>> >> would otherwise
>> >> allow it. A symbol isn't allowed to have @ in it, so this 
>> >> naturally
>> >> prevents a conflict. I realize the poor example, but it's 
>> >> definitely not
>> >> a keyword. Otherwise, it would be listed here:
>> >> http://www.digitalmars.com/d/2.0/lex.html#keyword 
>> >> (actually, are
>> >> annotations part of the lexical grammar there?).
>> >> 
>> >> It's more like Object, which is not a keyword, but you 
>> >> aren't allowed to
>> >> use it to mean anything besides what it means.
>> >> 
>> >> The end result is, it fails if you use it in the wrong 
>> >> place, but the
>> >> keyword status makes it fail at the parsing stage. I am not 
>> >> a compiler
>> >> writer, so I'm talking a bit from my ass here.
>> >> 
>> >> -Steve
>> > 
>> > Ok, maybe you're right. I'm pretty sure, as you say, that a 
>> > keyword in
>> > the wrong place would fail during parsing. But I don't know 
>> > where a
>> > misplaced annotation/attribute would fail.
>> 
>> Jacob is right here.
>> 
>> This, as you say, fails:
>> 
>> int struct;
>> 
>> And also this fails:
>> 
>> int @property;
>> 
>> So yes, currently @property is just a keyword with a prepended 
>> @.
>> 
>> Annotations in Java anc C# can have arguments. That is not the 
>> case in
>> D. For example, as it is said in DIP6, you could have:
>> 
>> @extern('C')
>> void someFunc();
>> 
>> instead of having extern a keyword and thus being unable to 
>> use it for
>> identifiers.
>
> No. No attributes are keywords. The reasoning is simple. A 
> keyword is a word
> that would be a valid identifier but isn't, because the 
> language treats it as
> special. @ is not a valid part of an identifier. So, @property 
> can't be a
> keyword. And property certainly isn't a keyword, since you 
> _can_ use it as an
> identifier, so it isn't a keyword with @ prepended on either.
>
> True, @property is treated as a special symbol by the compiler, 
> and I don't
> expect that it really treats it like an attribute with the name 
> property (which
> it will pretty much have to do if we ever get user-defined 
> attributes), but
> definitely isn't a keyword, because it was never possible for 
> it to be a valid
> identifier in the first place.
>
> - Jonathan M Davis

   I see eclipse4 used java annotations heavily to mark up code 
for dependency injection in the new ide framework.

Someone recommended use of mixin in this thread, in place of the 
java use of user defined annotations.  Is that still the 
recommended D solution for handling ports of java annotations?

https://wiki.eclipse.org/Eclipse4/RCP/Dependency_Injection