[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-dev] Named Advice revisited.

A compelling use case for named advice is to add additional crosscutting
behavior to the advice. Logging is a naïve example that doesn't require
names, but there are others such as caching the behavior of the advice that
requires advice specific behavior, changing the behavior of the advice using
another around advice, etc. and as we explore more applications for AOP more
usage will come up. IMHO not being able to advise an advice with the same
flexibility as methods is equivalent to saying that AO systems will always
be built in two layers, a class layer superimposed by an aspect layer. 

>simply create a method for the body, make the only line in the advice a
call to the
>method, and unit test the method.

Simply creating a method for the body is not sufficient in most cases. The
need for such a hack is an evidence that there is something wrong in the
current design and it
either requires ubiquitous up-front use of such delegation throughout the
program or requires that scattered changes are made to the aspects whenever
any of their advice bodies become subject to advising. Both these approaches
require source code, which may not always be available.

Delagating itself is not straightforward. You need to analyze the advice
body to determine whether or not they use special variables, thisJoinPoint,
thisJoinPointStaticPart, etc. or special methods such as proceed. All such
parameters have to be passed to the delegate method incurring additional
design- and run-time costs and risk of error. The situation is even more
complicated in cases of around advice that might use proceed in its body.
Proceed will have to be passed from the advice body to the delegatee as a
closure.

Bottomline is that delegation as an alternative to named advice is both
complicated and incurs the need for scattered changes, undermining the
purpose of aspects and there is a need to make advising advice as easy as
advising methods.

Rajan

P.S.: For a detailed discussion of these issues please look at my upcoming
ICSE 2005 paper available at
http://www.cs.virginia.edu/~eos/papers/p174-rajan.pdf