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.
My vote is for yes too.
2. Does "static *" match top-level types? I think the answer is yes.
Yes again.
Here are two sets of names in the attribute style:
@InterfaceType @ClassType @AspectType @InnerType @AnonymousType
@interface @class @aspect @inner @anonymous
Here are two sets of names in the sets style:
isInterface(), isClass(), isAspect(), isInner(), isAnonymous()
interface, class, aspect, inner, anonymous
Like Ron, I find the isInterface() style easiest to read right now.
However, knowing that the attribute style will be coming to the pointcut
language very soon once J2SE 1.5 is out, and being wary of pushing too
many new elements into the pointcut language, I think we should take a
good hard look at the attribute style. If we can find a way to do this
that will be compatible with the use of attribute-matching pointcut
expressions in general then that has a strong appeal to me. Especially
Jim's suggestion that the attributes could be defined in some package -
can we take this to the point where there is nothing special about these
particular attributes as compared to any others that we might wish to pick
out in the future? Figuring this out of course means we need to have some
discussion about the envisaged form of attribute-matching pointcut
expressions in aspectj in general.
Whatever route we go, there still remains the ambiguity in some situations
of whether the qualification refers to *this* or *target*.
e.g. call(@ClassType * *(..)) which is the @ClassType - this or target?
Probably target here... what if I wanted to specify *this*?
We'll either need a simple rule to handle this, or a way for the user to
specify (or both).
Like Wes, I like the notion of being able to name and compose
(type|method|field|...) patterns. My instinct is that adding these to the
language for 1.2 will be a tall order (unless we come up with a very
simple and clear design - both in the language and implementation - and
some compelling use cases), but our ultimate proposal for type patterns
should hopefully not preclude us from going down that road in a future
release should we want to.
-- Adrian
Adrian_Colyer@xxxxxxxxxx
"Jim Hugunin" <lists@xxxxxxxxxxx>
Sent by: aspectj-users-admin@xxxxxxxxxxx
16/12/2003 16:50
Please respond to aspectj-users
To: <aspectj-users@xxxxxxxxxxx>
cc:
Subject: [aspectj-users] Language: support for modifiers in
TypePatterns
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