(I’m CC’ing
users on this message because that’s where the unit testing discussion
took place)
The idea of named advice has popped up a
few times. Usually it’s because someone wants *labels* for advice,
e.g. for the IDE’s outline view, or for the stack trace entry in a
debugger thread tree. But labels are not the same thing as names and
could be added with an annotation on the advice. Names are used to invoke
things explicitly. The beauty and utility of advice comes from it being
invoked implicitly as the result of join point matching.
Recently another use case for naming
advice popped up on the list, as a means of explicitly invoking advice so that
it can be unit tested. In my opinion advice are not methods, and can not
be unit tested in the same way that methods can. When you unit test
methods you need to mock up the object parameters to the method, and then
invoke it explicitly. It seems to me that when you’re unit testing
advice you need to mock up the join point context in a way that invokes the
advice implicitly (i.e. create some kind of join point context object that
causes the appropriate pointcut to match by specifying signatures and type
patterns, setting the values of any args(), this() and target() referenced, and
possibly setting up anything needed from a cflow stack). Then you pass
your join point context and an aspect type reference to a unit testing
framework which is responsible for invoking the corresponding advice. If
you don’t care about all that context stuff, and really just want to unit
test the body of the advice, then simply create a method for the body, make the
only line in the advice a call to the method, and unit test the method.
Jean-Sebastien, you bring up a third use
case: adding names so that advice can be more easily matched by a
pointcut. In AspectJ 5 I already think that it’s convenient
enough. You’ve always been able to match advice using within(), and
now you’ll be able to match it using annotations on the advice. But
I’ve never seen a compelling use case for this, other than someone
suggesting that they might want to log all advice. Again, they can do
that without naming.
Other people’s opinion on this may
differ, but I see no need to make advice more like methods by giving them
names. When you want implicit invocation based on join point matching,
you use advice. When you want explicit invocation by name, you use
methods. Naming advice will muddy those waters. As you point out,
it will also add OOP inheritance facilities (e.g. overriding) to advice.
AspectJ’s stance is that AOP inheritance is about abstracting and
concretizing pointcuts, and not about extending and overriding behavior.
Notably other approaches such as JBoss
AOP and Spring AOP provide the latter for advice by
using method names for them, so we’ll learn more about those consequences
of that approach before too long.
So in short, I still haven’t heard
a compelling use for naming advice. But a discussion of these and other
potential uses of naming advice could be a useful research contribution.
Mik
From:
aspectj-dev-admin@xxxxxxxxxxx [mailto:aspectj-dev-admin@xxxxxxxxxxx] On Behalf Of Jean-Sebastien Boulanger
Sent: Friday, February 18, 2005 11:44 AM
To: aspectj-dev@xxxxxxxxxxx
Subject: [aspectj-dev] Named Advice
revisited.
As an experimental project I'm currently looking into
extending aspectJ syntax using the aspectbench compiler (www.aspectbench.org) to support
named advice. The extension will support pointcut that can match advices
by name.
I'm also trying to figure out what should be the
overriding rules for the named advice (if you can override or not a named
advice in a sub-aspect) and I red in the archive of the mailing list that the
idea that a named advice could override/extend advices with the same name is
'truly frightening'. I'm not sure I understand conceptually why it is so
frightening, maybe my mind is still thinking OO too much...anyway it would be
very appreciated if someone could explain to me in more details???