Re: [aspectj-dev] Named advice

["Ron Bodkin" <rbodkin@xxxxxxxxxxx>]

Backwards compatibility for binary aspect libraries is certainly a desirable quality. It appears that named advice would be a good way to achieve this, though there would surely be some subtleties (e.g., detecting changes in the context/pointcuts of advice).

I think named advice would be valuable for at least four other reasons:

1) It encourages describing behavior. When designing a system with aspects, I describe the advice (important behavior) early on, and it's natural to name the advice. In code, it's also nice to have a descriptive name as well as a comment.
2) It would allow picking out specific advices in adviceexecution PCD's. Perhaps we should also allow use of JSR-175 metadata tags on advice too (but that's another discussion...)
3) It would facilitate debugging and reading stack traces: you can see what advice is running by name instead of seeing ajc$before$coverage_Coverage$29c.
4) It will help newcomers to keep the concepts of pointcut and advice separate. Today, many see the idiom before() : namedPointcut() so much, they think of namedPointcut as the name of the advice...

The arguments I see against named advice are the implementation complexity and that having them not named emphasizes advice isn't called like a method, but automatically executes when a pointcut matches.

Perhaps named advice could be added as an option, and we'll see whether the community embraces it or not. I suspect it will become the norm.

Ron Bodkin
Chief Technology Officer
New Aspects of Security
m: (415) 509-2895

> ------------Original Message-------------
> From: "Matthew Webster" <matthew_webster@xxxxxxxxxx>
> To: aspectj-dev@xxxxxxxxxxx
> Date: Mon, Aug-18-2003 8:19 AM
> Subject: [aspectj-dev] Named advice
> 
> I have discovered another reason for named advice: backwards compatibility
> for binary aspect libraries.
> 
> Currently the advice name e.g. "ajc$before$coverage_Coverage$29c" is based
> on the position in the source file where the advice is declared.
> Unfortunately if a trivial change is made to the aspect e.g. a comment is
> added the name changes. This makes binary aspect libraries that use
> abstract aspects as an "interface" extremely fragile: any clients must be
> rewoven. Although current guidelines suggest keep advice as thin as
> possible small changes to the aspect may be necessary. It would also be
> nice to able to add pointcuts and advice, perhaps to the end of an aspect,
> and maintain backwards compatibility similar to that offered by Java
> classes. Was numbering of advice sequentially in the source, starting
> perhaps with $1 like anonymous inner classes, not considered?
> 
> I suppose what we really need is the equivalent of the serialVersionUID for
> object serialization with a name generated based on the definition of the
> pointcuts on which it depends.
> 
> Matthew Webster
> AOSD Project
> Java Technology Centre, MP146
> IBM Hursley Park, Winchester,  SO21 2JN, England
> Telephone: +44 196 2816139 (external) 246139 (internal)
> Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
> http://w3.hursley.ibm.com/~websterm/
> 
> The IBM Academy is sponsoring a conference on Aspect-Oriented Software
> Development, 3rd-4th September, Yorktown, NY.
> 
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-dev
>