[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