Re: [aspectj-users] refactoring code

[Andy Clement <andrew.clement@xxxxxxxxx>]

I found the @MatchCheck enhancement which you might want to read and
add comments to:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=254606

For loadtime weaving it is trickier but it is possible that a callback
exists in AspectJ and once the user believes their system has reached
a coherent they could call some method like
'AspectJ.verifyConstraints()' which then checks all constraints that
were expressed.

> Maybe I can set an error level if the pointcut does not have any wildcards
> and does not match, implying "must match"?

Right now we just have the adviceDidNotMatch xlint which can be
suppressed on a per advice basis, or turned up from warning to error.
Did you get this triggered in your scenario?  Yes, it could be smarter
about whether the pointcuts involve wildcards.

> Is there a planned list of what tool features are next?

Both AspectJ and AJDT have plans pages:

http://www.eclipse.org/projects/project-plan.php?projectid=tools.aspectj
http://www.eclipse.org/projects/project-plan.php?projectid=tools.ajdt

but maintaining those pages is quite tedious so the most reliable way
to see what is scheduled is to query bugzilla for what is targetted
for the next release, we work hard to keep bugzilla up to date and if
you want to see what is being fixed or worked on you can follow our
email IDs on bugzilla.

Here is the query for AspectJ 1.6.5: http://tinyurl.com/d4eqco - 134
bugs and enhancements that might be tackled (and no doubt more will
come in before 1.6.5 ships).  Over the last few releases typically
50/60 issues are addressed between releases, but as the codebase has
improved through the 1.6 releases the total number of open issues has
gradually declined - and that means we're slowly being left with just
the hard problems :)

If a bug has a  target then it is a candidate for the next release (it
will not necessarily be done, but it is a candidate).  If an issue has
no target there are currently no plans to do whatever it is (bug fix
or enhancement).  Raising new enhancements/bugs or voting/commenting
on existing ones is the best way to get things addressed or raise
their profile.  I've mentioned this before but just because a user is
seeing an issue all the time doesn't mean we know about it - so if in
doubt, always post here or raise it as a new issue.  I believe there
are some open issues for getting the normal refactorings to work in
the presence of aspects but can't recall if there are any open for new
refactorings (extract to ITD, that kind of thing).  Check the bug list
for AJDT.

cheers,
Andy.

2009/4/20 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
>
>
>
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>