Re: [aspectj-users] Language: support for modifiers in TypePatterns

["rbodkin" <rbodkin@xxxxxxxxxxxxxx>]

I really like this direction. I would very much like to see declare typename 
added because it overcomes a major drawback of declare parents: you often 
don't control the types you want to address in code you do control. With 
declare typename I'd like to be able to write this code:

declare typename: SupportedExceptions: 
    ServletException || JspException || RuntimeException || ...;
declare typename: SomeLibrary: org.thirdparty.library..*;

pointcut libraryCalls(): 
    call(* *(..)) && target(SomeLibrary); // calls into a library

pointcut overridingLibrary(): 
    scope() && execution(* SomeLibrary+.*(..));

declare warning: 
    execution(public * *(..) throws !SupportedException) && scope():
    "method throws illegal checked exception";

I'm also really glad to see support for matching type modifiers and for 
picking out types. I think the isInterface() syntax form is better than the 
metadata versions because it is easier to read and less "surprising" (it 
makes sense that we can think about types having metadata, but this will 
match types we don't control like those in the JDK).

On Tue, 16 Dec 2003 08:50:45 -0800, Jim Hugunin wrote
> Process note: This message is intended for BOTH aspectj users and
> developers.  I'm sending it to just the users list because I assume 
> that all developers will be reading both lists and I dislike having 
> two threads about the same topic.
> 
> This is the first of several messages to explore potential new language
> features for AspectJ-1.2.
> 
> The first proposed feature is to extend TypePattern to include 
> modifiers in the same way that modifiers are currently allowed on 
> method, field and constructor signature patterns.
> 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=44365
> 
> This example matches the static initialization of all public types:
>   pointcut publicInit(): staticinitialization(public *);
> 
> Most of the matching rules we have for other declarations translate easily
> to types.  There are two type-specific questions that must be answered:
> 1. Does "abstract *" match interfaces?  I think the answer is yes.
> 2. Does "static *" match top-level types?  I think the answer is yes.
> 
> There is one very annoying issue with syntax ambiguity.
> 
> Consider "execution(public * *(..))", does this match all public 
> methods or all methods whose return type is public?  This has to 
> continue to match all public methods or this would be an 
> incompatible change from AspectJ-1.1.
> 
> If you want to match all methods whose return type is public you'd 
> need to write, "execution( (public *) *(..))".  This is a reasonable 
> resolution of the ambiguity, but all of those parentheses make me a 
> little queasy.  I feel like I'm reading a C type declaration with 
> too many embedded function pointers.
> 
> I don't see any better solution to the syntax ambiguity than ()'s.  Using
> []'s would be worse because of confusion with array types.  Using 
> <>'s would be equally bad when we add support for generics.
> 
> <dangerous-proposal>
> C programmers solve this kind of problem by using typedefs to give a 
> name to complicated type patterns like this.  Several people have 
> made proposals in the past for a way to name type patterns.  We may 
> wish to consider something like this:  declare typename: 
> PublicFinalType: public final *;
> 
> This is probably not needed enough to do for the 1.2 release but if 
> we expand the complexity of the TypePattern syntax I'm certain that 
something
> like this will be demanded in 1.3.
> </dangerous-proposal>
> ----------------------------------------------
> 
> To make TypePatterns more powerful (and unfortunately more 
> complicated) we would also like to add the ability to match on 
> categories of types.  I believe the set of useful categories is 
> interface, class, aspect, inner, and anonymous.  The semantics of 
> matching these categories is obvious.  The best syntax is less clear.
> 
> I propose that we do this using the syntax that we expect to see for
> attributes in Java-1.5 from JSR-175.  Here's an example to match 
> join points within the public CLASSES in a package:  
> within(@ClassType public com.boxes..*)
> 
> Here are two sets of names in the attribute style:
> @InterfaceType @ClassType @AspectType @InnerType @AnonymousType
> @interface @class @aspect @inner @anonymous
> 
> The first set of names look like actual attribute types.  If using 
> them we may want to also require the import of some org.aspectj.lang 
> package that would define them.  The second set of names could be 
> thought of as reserved words.  Only the two names "inner" and 
> "anonymous" would have danger of name collisions.
> 
> Instead of treating these categories as modifiers, we could have some
> special type patterns that would match all members of a category and 
> use &&, || and ! for combining them.  The previous example to match 
> join points within the public classes in a package would look like:  
> within(isClass() && public com.boxes..*)
> 
> Here are two sets of names in the sets style:
> isInterface(), isClass(), isAspect(), isInner(), isAnonymous()
> interface, class, aspect, inner, anonymous
> 
> I believe that both modifiers and categories would be valuable 
> additions to
> 1.2.  The semantics of this feature doesn't appear to have any difficulties.
> I'm less happy with the syntax.  My personal opinion is that all of the
> syntax variants in this message are tolerable, but none of them are great.
> However, it's also clear that this change does noticeably increase 
> the complexity of AspectJ's already complex pointcut designator 
> language.  We need to proceed cautiously here.
> 
> -Jim
> 
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users



Ron Bodkin
Chief Technology Officer
New Aspects
m: (415) 509-2895