View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3820653#3820653
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3820653 Yeah, you are right in this example. My motivating example wasn't very motivating. :) AspectJ best practices recommends using cflow and cflowbelow as little as possible. In fact the Sable paper I mentioned in my e-mail (http://www.sable.mcgill.ca/publications/techreports/sable-tr-2003-8.pdf) used cflow in their implementation of Quicksort, which as you just pointed out was not necessary and can be done with a static check, as opposed to the horridly dynamic cflow check. public aspect DisplayUpdating { pointcut move(): call(void FigureElement.moveBy(int, int)) || call(void Point.setX(int)) || call(void Point.setY(int)) || call(void Line.setP1(Point)) || call(void Line.setP2(Point)); after() returning: move() && !cflowbelow(move()) { Display.needsRepaint(); } } public interface FigureElement { public void moveBy( int i1, int i2 ); } public class Point implements FigureElement { public void moveBy( int i1, int i2 ) { } ..... } public class Line implements FigureElement { public void moveBy( int i1, int i2 ) { p1.moveBy( i1, i2 ); p2.moveBy( i1, i2 ); } .... } In this case you have a little more complex control flow. Line.moveBy(int, int) calls Point.moveBy(int, int) for each point in contains, so trying to do a within for each different case becomes a small nightmore. ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
