Re: [aspectj-dev] pointcut diagnosis plug point

[Adrian Colyer <adrian.colyer@xxxxxxxxx>]

About a year ago I started work on a "pointcut reader" that could  
produce a "plain english" sentence describing what a pointcut  
expression would match. It's still half-finished on my hard-drive,  
must polish it off and make it available soon... The second part of  
that was  something that would tell you which join points the  
pointcut expression matched in a given codebase. The third part was  
the "explain" feature that for a given pointcut and join point would  
explain why the pointcut expression matched (or not) The matching  
algorithm that AspectJ uses is pretty amenable to giving this kind of  
output because it proceeds logically through the signatures of the  
join point etc.

A general analyzer mechanism for the "adviceDidNotMatch" message  
would be harder. adviceDidNotMatch is a result of attempting to match  
the pointcut at every join point shadow and failing on every  
occasion. So to explain this, we'd have to output (probably) hundreds  
of "this pointcut expression did not match join point ... because ...  
" messages. I think the interface for this one has to be something  
along the lines of :

explain join point matching for [pointcut-expression] (at join point  
kind(s) [list of kind])? (within <type-pattern> | withincode  
<signature-pattern>)?

Which could be supported in some form on the command-line, and  
integrated into AJDT.

On 3 Oct 2006, at 20:02, Wes wrote:

> A user complained that it took a while to figure out why something  
> like
>
>    call(* *(one, two)) && args(one)
>
> wasn't working.  It strikes me that there are some pointcuts that can
> be statically analyzed for these kinds of errors.  For ease of  
> development,
> I'd like there to be a way to plug in analyzers and have them  
> invoked on
> selected messages (e.g., adviceDidNotMatch).  The analyzer would get a
> reference to the world/pointcut after simplification and message sink.
> Good analyzers could be contributed and incorporated.  This might also
> be a way to evolve better LTW-specific messages.
>
> Would that be good/hard?
> Wes
>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev