Community
Participate
Working Groups
In ajc, it is possible to define a pointcut as "nothing" and an advice using this pointcut, in an abstract aspect. If the concrete aspect does not define this pointcut, it is the same as saying "it does not apply anywhere". One example here, from Hannemann/Kiczales Command design pattern: public abstract aspect CommandProtocol { ... protected pointcut setCommandTrigger(CommandInvoker invoker, Command command); after (CommandInvoker invoker, Command command): setCommandTrigger(invoker, command) { if (invoker != null) { setCommand(invoker, command); } else { // If the invoker is null, the command cannot be set. // Either ignore this case or throw an exception } } ... } public aspect MyCommandProtocol extends CommandProtocol {} This code compiles in ajc and the setCommandTrigger pointcut is kind of ignored, it does not match anything. However actually, it *should* say that the pointcut is unbound, because the parameters are not bound by the (empty) pointcut definition.
I find it very useful to have this ability to define the parameters that an empty pointcut matches, e.g., this is done in Glassbox as well as in the GoF design patterns. I would vote to leave the existing behavior alone. Otherwise we'd have to do something awkward like: protected pointcut setCommandTrigger(CommandInvoker invoker, Command command) : !within(*) && this(invoker) && this(command); What's the benefit of requiring users to write something so complex?
I think I don't understand. The pointcut definition... pointcut setCommandTrigger(CommandInvoker invoker, Command command); ... defines a contract that says that any implementor of that pointcut will expose two parameters with the correct types. So how can it make sense to provide a pointcut that does not bind those parameters - be it empty or not? To me it's mostly a matter of rules and exceptions and as it stands today, the AspectJ semantics IMHO have way too many exceptions of that kind.
If you know a pointcut will match no join points, why require binding parameters when it can never match? As I illustrated it's, of course, possible to write a pointcut definition that exposes parameters but won't match, but it is awkward. The reason for allowing it is because it is useful for developers. Is there a more elegant way of allowing you to define what context should be exposed by a pointcut while allowing it to default to matching no join points? You might consider it a form of syntactic sugar: useful for developers, helpful for optimization, even if it adds a bit of complexity to the language. I'd be unhappy if the feature were removed.
One more thought. I would say the pointcut definition... pointcut setCommandTrigger(CommandInvoker invoker, Command command); ... defines a contract that says that any implementor of that pointcut will expose two parameters with the correct types *at any join point that matches*. I don't see how you could talk about correct types without reference to the join point being matched. I believe that this expanded definition is met by the empty pointcut designators.
