Jumping in to this discussion, feel free to kick me out... :)
Seems like there are two overall strategies here: (a) ad hoc syntax and (b)
generic java expression syntax.
Option (a) is what Matthew is suggesting... takes a lot more work, gives
more flexibility. And the answer to the "member of array" question just
falls out if you choose option (a), e.g.
@Foo(Arrays.asList(value).contains(1)).
If you choose option (b) then not only do we have to invent a bunch of new,
custom syntax, there will be an endless round of bike-shed arguments about
what that syntax ought to be. But (b) is probably a lot more expedient
(especially if the project maintainers just dictate whatever syntax they
care to implement :)
So I think the first question that should be answered before getting into
all the details is: (a) or (b) ?
-Archie
On Fri, Apr 26, 2013 at 10:02 AM, Andy Clement <andrew.clem...@gmail.com>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...
>
> 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.*/")
>
> For numbers the usual set of operators seem ok. 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;
>
> cheers,
> Andy
>
>
> On 25 April 2013 20:08, Matthew Adams <matt...@matthewadams.me> 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
>> aspectj-users@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>
>
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
--
Archie L. Cobbs
_______________________________________________
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
