| RE: [aspectj-users] Simplification of generic / parameterized typ e matching in pointcut expressions |
Count me as a strong supporter for this simplification.
-----Original Message-----
From: Adrian Colyer [mailto:adrian.colyer@xxxxxxxxx]
Sent: July 27, 2005 7:29 AM
To: aspectj-users@xxxxxxxxxxx
Subject: [aspectj-users] Simplification of generic / parameterized type
matching in pointcut expressions
(This email contains a request-for-feedback on a proposed change to
the support for generics in pointcut expressions as documented in the
AspectJ 5 Developer's Notebook.)
We're making good progress on the upgrade of AspectJ's type system to
be fully generics aware. As a consequence we're starting to write many
more pointcuts and test programs in accordance with the specification
in the generics chapter of the AspectJ 5 Developer's Notebook
(http://www.eclipse.org/aspectj/doc/next/adk15notebook/generics-inAspectJ5.html).
We have also had the opportunity to share the design with a growing
number of people.
The current design pushes on the boundaries of what is possible given
the effects of erasure. However, two weaknesses are becoming apparent:
1) A strong understanding of Java's generic type system is required in
order to understand the subtleties of pointcut matching in some cases
- and most people do not have a strong understanding of Java's generic
type system. (For example, why execution(* Foo<String>.*(..)) is not
allowed, but execution(* I<String>+.*(..)) might be).
2) Pointcut expressions can quickly become confusing with generic
type information mixed in with all the other possible wildcards etc..
We propose a simplification of the design currently document in the
developer's notebook for the 1.5.0 release (and M3 milestone build).
The simplication is a subset of the the planned support for generics
in pointcut expressions as currently documented. In particular, we
propose not to allow generic or parameterized type patterns as the
*declaring type pattern* in any pointcut _expression_. This subsetting
is fully compatible with extending the language in the future to
support the additional features, but it will give us time to do this
in the context of real user experience writing AspectJ programs with
generics. In contrast, taking away features that later prove to be
ill-advised is much more difficult.
*** request for feedback ***
The simplification is documented below. We're especially interested to
hear from folks who either strongly support this change, or who have
compelling use cases that will not be supported by the proposed
simplification.
=============================================================
Simplified matching of generic and parameterized types in pointcut expressions:
You don't need to do anything special in pointcut expressions to match
generic and parameterized types: type patterns matching a Java type
name will match that type in any generic or parameterized context. For
example, the pointcut _expression_:
call(* List.*(..))
will match any call made to a method defined for the generic type
java.util.List. Likewise the pointcut
call(* process(List))
will match any call made to a method named process taking a List
argument (either the raw List type, or any parameterization such as
List<String>, List<?>, List<Double> etc.).
To match a method defined in a generic type, use the erasure of the
method signature. For example, given the type:
public class Foo<T> {
T doSomethingWith(T someObject) {
return someObject;
}
T getBest(List<T> listOfObjects) {
return listOfObjects.get(0);
}
}
You can match execution of the "doSomethingWith" method using the
pointcut _expression_:
execution(Object Foo.doSomethingWith(Object))
(wildcards are of course allowed, we just didn't use any in this
example).
To match the execution of the "getBest" method use the pointcut
_expression_:
execution(Object Foo.getBest(List<Object>))
Generic methods are also matched using their erasures. For example, a
call to the generic method
static <T> T newInstance(Class<T> ofSomeClass) { ... }
is matched by the pointcut _expression_
call(static Object newInstance(Class ofSomeClass))
Generic (eg. Foo<T>) or parameterized (e.g. Foo<String>) type patterns
are not permitted in a declaring type pattern. So "execution(*
Foo.*(..))" is legal, but "execution(* Foo<String>.*(..))" is not.
A parameterized type pattern may only be used as an argument type pattern
in method and constructor signatures, or as the field type pattern in
field signatures. For example:
call(* *(List<String>)
matches a call to any method taking a single argument of type
List<String>
call(* *(List<*>))
matches a call to any method taking a single parameterized list
argument (any parameterization)
call(* *(List<?>))
matches a call to any method taking a single argument of type List<?>.
get(List<String> *) matches the get of any field of type List<String>.
Given the type
public class Bar<T> {
List<T> aField;
}
Set join points for aField can be matched by the pointcuts
set(List<*> aField) and set(List aField), but not set(List<T> aField)
(which will give a type not found error for T).
In order to enable advice to be written in fully generic type-safe
manner, it is desirable to allow parameterized types to be used in
this, target, and args expressions. The consequences of erasure mean
that this is not possible for this and target, and only partially
achievable for args.
Args matching using parameterized types works as follows... (see
current chapter in dev notebook).
-- Adrian
adrian.colyer@xxxxxxxxx
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
CONFIDENTIAL AND PRIVILEGED INFORMATION NOTICE This e-mail, and any attachments, may contain information that is confidential, subject to copyright, or exempt from disclosure. Any unauthorized review, disclosure, retransmission, dissemination or other use of or reliance on this information may be unlawful and is strictly prohibited. AVIS D'INFORMATION CONFIDENTIELLE ET PRIVILÉGIÉE Le présent courriel, et toute pièce jointe, peut contenir de l'information qui est confidentielle, régie par les droits d'auteur, ou interdite de divulgation. Tout examen, divulgation, retransmission, diffusion ou autres utilisations non autorisées de l'information ou dépendance non autorisée envers celle-ci peut être illégale et est strictement interdite. |