Community
Participate
Working Groups
FastMatch, the efficient pattern matching for pointcuts on the constant pool, is currrently only implemented for the within pointcut. I am planning to provide further oimplementations for other pointcuts by release 1.2.
I've marked this bug as target 1.2 so that we remember to track anything you can do here as part of the 1.2 release.
Created attachment 8114 [details] Implements recognition of if(false) during FastMatch With this patch if(false) is evaluated to FuzzyBoolean.NEVER during FastMatch.
I submitted a small patch for FastMatch of IfPointcut. This adresses the idiom "somePointcut() && if(false)" which is often used to temporarily exclude certain pointcuts for debug purposes. Such a pointcut is now automatically evaluated to "NEVER" match.
Created attachment 8118 [details] Part two of the patch for handling of if(false) This prevents a method to be generated at all for if(false).
First off I've renamed this bug to reflect what you're working on. This is not a fast match issue and that's somewhat confused your solution. The right way to implement this feature is to modify IfPseudoToken to return a Pointcut.MatchesNothing object for the special case of if(false). This will produce a pointcut that has all of its methods correctly implemented to handle a pcd that can matches no join points. There are several problems with your solution. Starting with the fastMatch change: FuzzyBoolean.NEVER is a very special value that isn't correct here. You should just use FuzzyBoolean.NO as is used in the WithinPointcut that I pointed you at as the canonical example for fastmatch. This is important for the case where someone uses !if(false) either directly or through a named pointcut. You also can't just modify fastMatch without making similar modifications to the core match routine. Because of things like !if(false) you need to be prepared to handle a normal match call -- I believe your solution would create a call to a non-existant method in this case. I can't believe that you wrote this code: if (this.expr.getClass()==FalseLiteral.class) return; Reflection should be used sparingly and only when really needed. Use "this.expr instanceof FalseLiteral" if you must test for type. Even better would be to use methods on Expression if those are available.
I've implemented a variation on Jim's suggestion for if(false) and if(true). Will resolve the bug as fixed once these are available in a build.
Fix available in latest build from www.eclipse.org/aspectj.
Fix released as part of AspectJ 1.2.1
