Summary: | variable bindings not checked in empty pointcut definitions | ||
---|---|---|---|
Product: | [Tools] AspectJ | Reporter: | Eric Bodden <eric> |
Component: | Compiler | Assignee: | aspectj inbox <aspectj-inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | normal | ||
Priority: | P5 | CC: | aclement |
Version: | unspecified | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Eric Bodden
2006-10-05 14:30:32 EDT
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. |