[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[aspectj-users] Re: pointcut for super.*(..)
|
On 25-Mar-09, at 10:03 AM, Andy Clement said:
I'm afraid super calls are not join points. Apply some advice against
'within(B)' and you won't see it recognizing any join point for the
super
call - so you can't write a pointcut for it.
IMHO, the fundamental reason that super has no join-point is that
super calls are not actually calls; although Java implementations tend
to supply an execution join point for the super method. But, with a
continuation-based understanding of join-points [see my disertation],
super calls are not principled in the sense of the original AOP
paper. It is an artifact of the Java language that invokespecial
exists to support super. To understand this, one could imagine
inlining the super code (in many/most situations) without violating
well-accepted principles of OO programming (e.g. objects accept
messages, the Liskov's substitution principle, ...). Inlining would
make the entire call disappear. An invokevirtual never can disappear
because message passing is fundamental to OO, and enumerating the
accepted methods are fundamental to characterizing a specific object/
class.
Thinking of AOP as pre-processor technology, (rather than just
implemented as a compiler or pre-processor) leads one down the
slippery slope of making any expression, piece of code, or other
textual unit into a join point. That leads to the complexity of full-
blown reflection tools implemented as rewriting systems. The goal of
AOP is to provide the essential power of reflection, without the full
complexity of meta-level architectures (cf. Jim Hugunin's talk at the
2005 PDC).
I hope that super never becomes a join point (just like "as an
argument to a method", or "a case statement", or "lines 47--53 of
foo.java) never become join points. When that happens, AspectJ will
join all the other unprincipled techniques of program rewriting.
Chris Dutchyn