*Warning: I had to put my thinking cap on. The reader might need to as well, unless I'm just a lot dumber than said reader, which is entirely possible.*
On Fri, Apr 26, 2013 at 10:02 AM, Andy Clement <[email protected]>wrote: > I think that would be great, and would provide a lot of flexibility - but > it is quite a lot of work... Most cycles are going to get consumed on > supporting Java 8 for the next little while. I'm sure when you start > thinking about type annotations (jsr308) you are going to come up with a > million new AspectJ use cases... > > True, true. > For strings I might be happier with using a regex of some kind rather than > getting into what methods are or are not allowed. > > @Foo(value =~ "/^goo.*/") > > Me likey this, since there's not a Java "=~" operator. What about a tip o' the hat to Groovy and use operator "==~" instead? http://groovy.codehaus.org/Regular+Expressions > For numbers the usual set of operators seem ok. > Whew. > I'm still waiting for someone to tell me the best operator for that > 'member of array' construct we were talking about previously: > > @Foo({1,2,3}) > > declare @type: @Foo(value ???? 1): @ContainsOne; > > I don't know that a single operator will suffice. My description in the issue (https://bugs.eclipse.org/bugs/show_bug.cgi?id=405016#c0) requests the ability to use the ordered collection semantics, which can't really be expressed as a single operator. Your example would be expressed as declare @type: @Foo(value = {..,1,..}): @ContainsOne If the parser doesn't like "{" or "}", can it be *made* to like them? If not, how about square brackets? declare @type: @Foo(value = [..,1,..]): @ContainsOne These would also match (using curlies): declare @type: @Foo(value = {1,..}): @StartsWithOneAndHasZeroOrMoreAdditionalElements declare @type: @Foo(value = {1,*,*}): @StartsWithOneAndHasExactlyTwoAdditionalElements If you really want a single "contains" operator, then how about "=*"? declare @type: @Foo(value =* 1): @ContainsOneSomewhereInArray The examples so far only are considering a single argument on the right-hand side. What about the notions of "contains any" and "contains all", disregarding order? My company currently has a DSL that uses the "!" character to mean "required" or "non-null" and the "?" character to mean "optional" or "nullable". In this context, we could define "contains all" as "=*!", and "contains any" as "=*?". Examples follow, using a parenthesized collection literal syntax (as opposed to Java's {} array literal syntax, which implies order and as opposed to Groovy's [] syntax for maps or arrays). declare @type: @Foo(value =*? (1, 2)): @ContainsOneOrTwoAnywhereInArray declare @type: @Foo(value =*! (1, 2)): @ContainsOneAndTwoAnywhereInArray This, along with the curly brace construct where ordering semantics would then support many, if not all, of the use cases I could dream up. Summary of my suggested operators follows. Note: below, SVAV means "single-valued annotation value", MVAV means "multivalued annotation value". Expression Description = x "equals singly": matches a SVAV where x is a single element = {...} "ordered matches": matches a MVAV where ... is an ordered expression using literals, .. and * =* x "contains": matches a MVAV where x is a single element and contained anywhere in the array of values =*? (...) "contains any": matches a MVAV where ... is an unordered set of values =*! (...) "contains all": matches a MVAV where ... is an unordered set of values WDYT? cheers, > Andy > > > On 25 April 2013 20:08, Matthew Adams <[email protected]> wrote: > >> So as I've been kicking around some of the type expression enhancements, >> in >> particular, https://bugs.eclipse.org/bugs/show_bug.cgi?id=405016, it >> occurred to me that, IMHO, there should be a limited type expression >> syntax >> for matching annotation values. >> >> For example, consider annotation values of type String. It would be nice >> to >> match case sensitively, insensitively, or even match a regex. The syntax >> for that could look something like the following type expression examples. >> Given >> >> public @interface Foo { String value(); } >> >> these would be allowed: >> >> (@Foo(value = "goo") *) >> (@Foo(value.equals("goo")) *) // same as above >> (@Foo(value.equalsIgnoreCase("goo")) *) >> (@Foo(value.startsWith("goo")) *) >> (@Foo(value.endsWith("goo")) *) >> (@Foo(value.matches("go{2}")) *) >> (@Foo(value.trim().length() > 0) *) >> ... >> >> Any appropriate method or expression that returns boolean seems >> supportable. >> >> As for numeric types (primitives & wrappers), given >> >> public @interface Bar { int value(); } >> >> these would be allowable: >> >> (@Bar(value > 10) *) >> (@Bar(value >= 0 && value < 10) *) >> (@Bar(value % 2 == 0) *) >> ... >> >> Since these type expressions are evaluatable statically (since all >> annotation values must be constants), this seems fully validatable at >> compile time. >> >> Thoughts? >> >> -matthew >> >> >> >> -- >> View this message in context: >> http://aspectj.2085585.n4.nabble.com/Type-expression-matching-annotation-values-String-matching-numeric-ranges-etc-tp4650906.html >> Sent from the AspectJ - users mailing list archive at Nabble.com. >> _______________________________________________ >> aspectj-users mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/aspectj-users >> > > > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > > -- mailto:[email protected] <[email protected]> skype:matthewadams12 googletalk:[email protected] http://matthewadams.me http://www.linkedin.com/in/matthewadams
_______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
