Summary: | Add annotation value support for type java.lang.Class[] | ||
---|---|---|---|
Product: | [Tools] AspectJ | Reporter: | Matthew Adams <matthew> |
Component: | Compiler | Assignee: | aspectj inbox <aspectj-inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | aclement |
Version: | 1.7.2 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Mac OS X | ||
Whiteboard: |
Description
Matthew Adams
2013-04-05 11:58:46 EDT
WRT the "contains" semantics, did you decide on "=" v. "{}"? That is, will "=" be overridden to mean "contains" in the case of testing for a single value? (Discussed at http://aspectj.2085585.n4.nabble.com/Matching-on-one-of-an-annotation-s-values-in-a-multivalued-property-tp4650839p4650846.html) Also, are you intending to deliver this with 1.7.3? "Target Milestone" isn't yet identified for this issue. class literals are now supported, just committed that. Arrays are not, that is more complicated because the parser doesn't appear to be allowing { } chars through as pseudotokens for the pointcut parser. I'm not happy about abusing = to also mean 'contains' in addition to equality, but I haven't put any brainpower into a better syntax yet. (In reply to comment #3) > class literals are now supported, just committed that. > Dude. Sweet. > Arrays are not, that is more complicated because the parser doesn't appear > to be allowing { } chars through as pseudotokens for the pointcut parser. > Not sure what that means to me, a mere layman. > I'm not happy about abusing = to also mean 'contains' in addition to > equality, but I haven't put any brainpower into a better syntax yet. I'm ok with it since given public @interface Foo { String[] value(); } the following Java sources are equivalent: @Foo("goo") @Foo({"goo"}) The only problem I can forsee is when you match on syntax (not type) and want to match an annotation that has a single valued attribute. For example, if "=" is overloaded to embody both "equals" & "contains" and given package org.example.foo; public @interface Foo { String value; } and package org.example.bar; public @interface Bar { String[] value; } then you could not create a type expression that will select, say, any class annotated with any annotation that has a single-valued String attribute with value "goo": (@*(value = "goo") *) // ambiguous if "=" means "equals" or "contains" The above would not be ambiguous if "=" were not overloaded. Given that overloading would make that kind of unique selection impossible, I suppose that I'm left supporting the idea of ensuring "=" is not overloaded, and being forced to use either "=" or "{...}" to differentiate. (In reply to comment #4) > > I'm not happy about abusing = to also mean 'contains' in addition to > > equality, but I haven't put any brainpower into a better syntax yet. > I'm ok with it since given > ... > The above would not be ambiguous if "=" were not overloaded. Given that > overloading would make that kind of unique selection impossible, I suppose > that I'm left supporting the idea of ensuring "=" is not overloaded, and > being forced to use either "=" or "{...}" to differentiate. Just want to be clear that I flip-flopped on my preference after typing out loud and think that "=" should NOT be overloaded with both "equals" and "contains". "=" should only match single-valued annotation attributes and "{...}" should only match multivalued annotation attributes. :) |