[PRL] AspectJ "feature"

[Jeffrey Palm]

Karl Lieberherr wrote:

> 
> Hi John and Matthias:
> 
> This is bad. Gregor is aware of this problem. 
> 
> We work on a partial solution to this by studying the unsatisfiability
> problem for pointcuts. Whenever you change your program and one of your
> pointcuts becomes unsatisfiable, the compiler will throw a red flag. Not
> perfect, but a step in the right direction.
> 
> -- Karl

Yes, this is a step in the right direction, and it's useful, but I think 
Walker and the others at Princeton have it right by making exposing 
pointcuts as part of the interface.  This particular problem that John 
mentions is trivially solved..  The harder on (i.e. NP hard) is when you 
add cflow, etc.

Jeff

> -----Original Message-----
> From: prl-bounces at lists.ccs.neu.edu
> [mailto:prl-bounces at lists.ccs.neu.edu] On Behalf Of Matthias Felleisen
> Sent: Tuesday, April 05, 2005 12:14 PM
> To: John Clements
> Cc: PRL Mailing List
> Subject: Re: [PRL] AspectJ "feature"
> 
> 
> We don't need a semantics for our languages, because we don't need to 
> reason about our programs.
> 
> On Apr 5, 2005, at 11:22 AM, John Clements wrote:
> 
> 
>>It's rude of me to crow, but I noticed (and Jeff Palm confirmed) a 
>>bizarre "feature" of AspectJ that explains something about how they 
>>think.
>>
>>Here's a simple "Counter" class.  Increment mutates x, and legalDx (if
> 
> 
>>it were called) checks that dx is > 0.
>>
>>public class Counter {
>>	int x;
>>	Counter(int x) {this.x = x;}
>>	
>>	void increment(int dx){this.x += dx;}
>>	boolean legalDx(int dx){return dx > 0;}}
>>
>>Here's a tiny example of creating a counter and calling increment:
>>
>>public class CounterTest extends TestCase {
>>	public void test(){
>>		Counter c = new Counter(14);
>>		c.increment(-4);}}
>>
>>Here's an aspect that adds a check on the argument passed to
> 
> increment:
> 
>>public aspect CheckDx {		
>>	before(Counter c, int dx): target(c) && args(dx) && call(void 
>>increment(int)) {
>>		if (! c.legalDx(dx)) {
>>			System.out.println("Illegal value for x");
>>			return;}}}
>>
>>So, if increment is called with negative dx (as it is above), you'll 
>>get output on stdout.
>>
>>All fine, and works as expected.
>>
>>QUIZ QUESTION: what happens if you make a mistake in the name of the 
>>method called inside the advice?  E.G:
>>
>>...
>>		if (! c.legalwhoopsbadnameDx(dx)) {
>>...
>>
>>
>>What happens is...
>>
>>
>>nothing.  No compile error, runs fine.  The advice is _not_ applied, 
>>no output to stdout.  I can only guess that type information from the 
>>body (in this case, the existence of a 'legalwhoopsbadnameDx' method) 
>>is implicitly added to the pointcut,
>>
>>Now imagine you're working on a 100KLoc program, and you change the 
>>name of a method.  You change all the uses of the method (using 
>>compiler error messages, say), until it compiles.  And runs!  
>>Unfortunately, your aspects no longer apply to the same join points 
>>that they used to.  Yikes!
>>
>>Is this something that Gregor et. al. consider "the right thing?"
>>
>>
>>john
>>_______________________________________________
>>PRL mailing list
>>PRL at lists.ccs.neu.edu
>>https://lists.ccs.neu.edu/bin/listinfo/prl
> 
> 
> 
> _______________________________________________
> PRL mailing list
> PRL at lists.ccs.neu.edu
> https://lists.ccs.neu.edu/bin/listinfo/prl
> 
> 
> _______________________________________________
> PRL mailing list
> PRL at lists.ccs.neu.edu
> https://lists.ccs.neu.edu/bin/listinfo/prl
> 
> 


-- 
Jeffrey Palm --> http://www.ccs.neu.edu/home/jpalm