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

["Jim Hugunin" <lists@xxxxxxxxxxx>]

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