Community
Participate
Working Groups
I would like to be able to use a public modifier in type patterns, to only pick out public types. This should also allow !public to pick out only types with default access. This would add public _TypePattern_ to the grammar for TypePatterns. For example, in: public pointcut publicJoinPoints() : execution(public * *(..)) || execution(public new(..)) || preinitialization(public new(..)) || initialization(public new(..)) || staticinitialization(/*public*/ *) || ...; I'd like to use public * in that staticinitialization pointcut, to restrict the definition of the public interface to include only publicly visible types.
Support for ALL other modifiers like private, synchronized, volatile ... would be great too.
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.
I would like to take a good look at this for AJ5 M4...
what is the status of this ? I would love to be able to specify modifiers like private, synchronized, volatile in my pointcut.
Until M3 is complete (mid July) we won't look at anything targetted M4 - which this is...
We're not going to get to this in AJ 1.5.0. Marking as "LATER" for consideration in 1.5.1 and future release planning.
Anything planned here?
not in the short term... if you have another use case/scenario, please append it to this bug.
LATER/REMIND bugs are being automatically reopened as P5 because the LATER and REMIND resolutions are deprecated.
committed support for this. There is now a type pattern called is(...) where the ... can be: AnnotationType/ClassType/EnumType/InnerType/AnonymousType/InterfaceType so: within(!is(AnonymousType)) I may fold the AnonymousType into the type pattern itself sometime later, but not right now as that is a lot of work.
