[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [aspectj-users] Plans for the next release of AspectJ...
- From: Ramnivas Laddad <ramnivas@xxxxxxxxx>
- Date: Tue, 9 Dec 2003 09:09:38 -0800 (PST)
- Delivered-to: firstname.lastname@example.org
--- Ron Bodkin <rbodkin@xxxxxxxxxxxxxx> wrote:
> 3. Related to 41952, I'd like to see a TypePattern operator -, which
> is the opposite of +. This will let you talk about methods defined on
> a given type without being vulnerable to pull up refactorings
> breaking the code, e.g., you write a PCD with a signature like *
> MyClass.foo(..) or * MyClass.*(..)). Then someone refactors and makes
> MyClass extend Abstract, and pulls foo up to be defined in Abstract.
> Now your PCD breaks! Now, in a dynamic context the better alternative
> might be to use something like this(MyClass) && execution(* foo(..)),
> but this won't help in withincode nor for static methods.
> If you could write * MyClass-.foo(..) or * MyClass-.*(..) your
> pointcut would be more robust; the refactoring wouldn't cause
> problems. It would also avoid surprises when you override a method
> and suddenly it IS captured by the PCD.
> The bigger question is whether this MyClass- behavior should be a
> default (maybe the current behavior could be defined as
> exactly(MyClass).foo or MyClass defines foo or ???).
I think this may be a case where backward incompatibility may
be better than carrying the current behavior along for the
versions to come.
I will like call(* MyClass.*(..)) to capture call to any method
that is part of the MyClass's interface regardless whether
a method is implemented in MyClass or in a superclass.
The reason is very much along what Ron is suggesting. I will like
the crosscutting to not break after performing "Move up method"
refactoring. Such a refactoring would not have changed anything
of semantic importnance.
> Ron Bodkin
> Chief Technology Officer
> New Aspects of Security
> m: (415) 509-2895
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.