RE: [aspectj-dev] Use of non-statically resolvable pointcut designators

["Dale Asberry" <lists@xxxxxxxxxxxxxxx>]

FWIW, I understand how/why people are trying to use cflow in the declare eow.  They are trying to determine if a particular pointcut is/nt in the scope of another pointcut.  The email from earlier today was attempting to find if a particular join point existed in the set of join points that would be a staticly determinable analogue of cflow.  This is suggesting to me that AspectJ needs new types of join points representing mathematic "set" operations.

Here's an example of when it might be useful:
JDBC operations in working apps with db specific issues.  For instance, I'm working on a J2EE app going against a DB2 database.  The connection pool has problems (in my environment) recognizing when each connection is finished.  This means that conn.commit() needs to be called after rs.next() but before conn.close().  I can visually inspect the code and "see" this pattern and hence makes it statically determinable.  Using set theory, I can do something like the following

codeblock(* DAOClass+.getObject(..))) intersection !call(void Connection.commit())

which would conceptually match all getObject() method definitions where commit() is NOT called.  Just taking a moment and I realize the kind of very interesting and incredibly powerful join points this leads to... 

codeblock(call(* ClassA.method1(..)) union call(* ClassB.method2(..)))

which would allow me advise a block of code of interest that is NOT necessarily at the OO level:

public class ClassC{
     public void sample(){
          ClassA aVar = new ClassA();
          ClassB bVar = new ClassB();
          ...do stuff...
          //Start of codeblock
          aVar.method1();
          ...do some more stuff...
          bVar.method2();
          //End of codeblock
     }
}

public aspect AspectD{
     pointcut pc(): codeblock(call(* ClassA.method1(..)) union call(* ClassB.method2(..)));

     around(): pc(){
          synchronized{proceed()};
     }
}

This could be incredibly powerful.