Hi Archie,

I didn't see your message before my last reply.  I really could go with
either (a) or (b), but I feel more invested in (b).  I can't speak to the
difficulty of implementation of either strategy -- the AspectJ team would
have to comment.

While the Java familiarity afforded by (a) is appealing, the verbosity is a
turn-off for me.  AspectJ pointcuts already are very terse and a bit
cryptic for the uninitiated, so I'm not afraid of just continuing down that
road with (b).

Check out my suggestions and please comment with your thoughts.

-matthew


On Fri, Apr 26, 2013 at 10:19 AM, Archie Cobbs <[email protected]> wrote:

> 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 
> <[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...
>>
>> 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 <[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
>>
>>
>
>
> --
> Archie L. Cobbs
>
> _______________________________________________
> 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

Reply via email to