Community
Participate
Working Groups
There are several interesting use cases for annotations, e.g. @Singleton, binding annotations or @Test to define Junit4 test methods. However, full support for annotations touches many aspects of the language, some of them seem to be hard to tackle or require considerable efforts (assuming we use the Java like syntax where annotations precede the annotated element): - The parser would need larger lookahead to decide which path to go: declared dependency or operation. This may effect content assist. - Validation is required to ensure the annotations are not misplaced - Java7 will likely support annotations for type parameters JSR308 - either we do not support that or we need to be aware of the target platform, e.g. the used Java version - Annotations may take arguments which may be of any primitive type, Class, String, other annotations, or a one dimensional array of one of these things. Java allows to write expressions there as long as the compiler can evaluate them statically. Especially problematic seems the support for arrays. - we already decided to use the override keyword instead of @Override which may be counter intuitive as soon as annotations are allowed - Validation is required for annotations that are inherited However, since annotation support has many advantages, we could think about a limited support for them as a first shot and postpone many of the tricky parts, e.g. we could only allow literals instead of full expressions.
(In reply to comment #0) > - Java7 will likely support annotations for type parameters JSR308 - either we > do not support that or we need to be aware of the target platform, e.g. the > used Java version Correction: JSR308 was postponed to Java8 so annotated type parameters should not affect the complexity of Xtend's annotation support for now
(In reply to comment #0) > There are several interesting use cases for annotations, e.g. @Singleton, > binding annotations or @Test to define Junit4 test methods. Not to mention all the other Junit4 and Guice annotation as well as our own Annotation based APIs (@Check). Just to make clear that hard coding this stuff into the language as we started with @Inject is a dead-end. > - The parser would need larger lookahead to decide which path to go: declared > dependency or operation. This may effect content assist. You are implying that we also switch our dependency declaration to real fields. We could still syntactically require '@Inject' at that position. But that doesn't seem sound, does it? The lookahead problem happens mostly because of the optional name in fields and the optional return type in functions. If we make the name of a field mandatary, things should work out better. > - Java7 will likely support annotations for type parameters JSR308 - either we > do not support that or we need to be aware of the target platform, e.g. the > used Java version That's a problem of the future. > - Annotations may take arguments which may be of any primitive type, Class, > String, other annotations, or a one dimensional array of one of these things. > Java allows to write expressions there as long as the compiler can evaluate > them statically. Especially problematic seems the support for arrays. We could support the literals as well as references to static literals (enums, constants). Java has this sugar for Array initializers in the context of annotations. We could support just that. Maybe even not only for single annotation values, but also for multiple. > - we already decided to use the override keyword instead of @Override which may > be counter intuitive as soon as annotations are allowed If we make the decision soon enough I'd want to change that.
I think this should be a reusable layer between Xbase and Xtend. Project-wise it should go into Xbase.
After having slept over this, I don't think override should become a keyword. In that case we would need to discuss all other modifiers as well which would open up a whole new can of worms. I think we should use keywords for modifiers used by the language implementation. Regarding the field and the optional name: We could allow omitting the name only if a field is declared using the 'extension' keyword.
(In reply to comment #2) > Just to make clear that hard coding this stuff > into the language as we started with @Inject is a dead-end. > It is, indeed no option. > > - The parser would need larger lookahead to decide which path to go: declared > > dependency or operation. This may effect content assist. > > You are implying that we also switch our dependency declaration to real fields. > We could still syntactically require '@Inject' at that position. But that > doesn't seem sound, does it? The @Inject keyword would only work as long as we don't allow to define 'normal' fields in Xtend which is worth to discuss. @MyAnnotation(types={., .}, other={@OtherAnnotation(..), ..) methodName / FieldType is actually infinite lookahead for the parser. We could try to make compromises with the AST and introduce something like an AnnotatedXtendMember which wraps the actual function or dependency. But that's more or less a technical problem which should be discussed in-depth offline. > > - we already decided to use the override keyword instead of @Override which may > > be counter intuitive as soon as annotations are allowed > > If we make the decision soon enough I'd want to change that. I'm thinking about a quickfix that converts @Override to the override since I prefer the keyword as it affects validation rules and things like that. But I'd be ok with java.lang.Override, too.
Annotations should be allowed before classes, fields (we should rename the concept 'declared dependency' to field) and functions.
I've pushed a first draft of grammar, scopeprovider and compiler. Todos: - validation - tests - update docs
pushed to master
Closing all bugs that were set to RESOLVED before Neon.0
