Re: [aspectj-users] refactoring code

[Michael McCray <mike@xxxxxxxxxxxxxxxxx>]

The annotation suggestion of @MustMatch is like the @Override for Java.  I can see that that is intuitive, but what if the aspect isn't in your build unit as in LTW?  Maybe it just wouldn't apply?  What about a declare matches pointcut(); type of constraint?

A pointcut is like a typedef, but more lenient.  I have never liked the "*" wildcard notaion, it seems too loose and not meaningful.  If there was a semantic kind of markup that the code had that the pointcut could refer to aspects would be more intuitive and direct to the point.  Maybe I can set an error level if the pointcut does not have any wildcards and does not match, implying "must match"?

Is there a planned list of what tool features are next?  Is wider refactoring support already being worked on?  I have wanted this ability for a while.  What about other features like "copy pointcut", and then while entering a pointcut it would auto suggest the various widening options?

Do people like to refactor their code into aspects?  I think sometimes the aspect is first, but othertimes, it can be discovered from code cleanup activities?

Do people rely on unit tests for their aspect matching?

Mike

On Mon, Apr 20, 2009 at 4:15 PM, Andy Clement <andrew.clement@xxxxxxxxx> wrote:

There an open enhancement (I can't seem to lay my hands on the number
with a quick search...) where the advice can be annotated with a kind
of assertion, and when the assertion breaks it triggers a
warning/error.  Something like @MustMatch or
@ExpectedToMatch(places=5).  Sounds like that would have helped here.

Andy.

2009/4/20 Andrew Eisenberg <andrew@xxxxxxxxxxxx>:

> Hi Mike,
>
> There is currently no refactoring support for pointcuts.  So, if a
> pointcut refers to a name that has changed, there will be no
> notification of this.
>
> This is something that has been discussed many times in the past, but
> so far there has not been any proposed solution intregrated into AJDT.
>
> In earlier versions of AJDT, there was a crosscutting comparisons
> view, which would allow you to see how your crosscutting model has
> changed compared to an earlier version of the model.  This feature,
> unfortunately, had to be removed due to incompatibilities with the new
> mechanism for creating the crosscutting model introduced in 1.6.1
> (what was lost in functionality was made up for by significant
> compilation speedup).
>
> I would recommend that you raise a bug for pointcut-aware refactoring
> on bugzilla and if you are interested in contributing to the project,
> we can help guide you along.
>
> --a
>
> On Mon, Apr 20, 2009 at 1:12 PM, Michael McCray <mike@xxxxxxxxxxxxxxxxx> wrote:
>> Hi all,
>>
>> I changed a method to public from protected while refactoring.  I had some
>> advice that referred to this method with the whole qualifier (protected void
>> myMethod()), so my advice did not apply.  How hard would it be for AJDT to
>> refactor the pointcut during method alterations?  Or maybe an advice report
>> that shows pointcuts that dropped because of a particular refactoring?  I
>> didn't have a unit test for this particular piece of code, so that would
>> have notified me of the issue.  Is this the recommended direction?  That
>> seems hard to maintain as a crosscutting concern could be quite widely used.
>>
>> Mike
>>
>>
>>
>> _______________________________________________
>> aspectj-users mailing list
>> aspectj-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>
>>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users