Re: [aspectj-users] If pointcut and side effects

["Jon S. Baekken" <jbaekken@xxxxxxxxxxxx>]

Interesting. It would certainly feel more intuitive if pointcuts were evaluated in order relative to the advice they're associated with. Of course, evaluation must if needed happen at the join point - the problem is when there are multiple advice at the same join point. It can't all happen at the same time.

Btw, this issue doesn't stop with the if, but goes for other dynamic checks as well, e.g. when around advice changes the arguments to the join point, which apparently impacts the args pointcut of a lower-precedence advice. This example is constructed; I don't know if things like this are likely to happen in real programs:

public class C1 {

public static void main(String... args) {

C1 c1 = new C1();

c1.m(c1);

}

public void m(C1 c) {

System.out.println("m");

}

}

public class C2 extends C1 {}

public aspect A {

void around(C1 c1) : call(void m(..)) && args(c1)

{

System.out.println("around in");

proceed(new C2());

System.out.println("around out");

}

before() : call(void m(..)) && args(C2) {

System.out.println("before");

}

}

around in

before

m

around out

Jon

On Jun 22, 2006, at 10:58 AM, Wes wrote:

what interest is it to check it if

one

doesn't know when the check is going to happen?

Originally I said that an implementation of AspectJ is free to reschedule

if-PCD evaluation if it could do so correctly.

I agree that it wouldn't be correct to evaluate an if-PCD statement

before starting the join point if the statement relied on a variable that

the program thread can change.*  Further, I think there's some argument that,

e.g., more-precedent before advice should be able to set the variable and

have the change be visible when evaluating the pointcut for less-precedent

advice.  That's a policy point we could and perhaps should say.

However, since we've said the if-PCD evaluation itself should be free of 

side-effects, you shouldn't rely on setting the variable in an if-PCD

evaluation for the more-precedent before advice.

For an example of studied indeterminacy, see Java thread priorities,

made expressly unreliable to support different platform.  In that

case, the programmer has tools to ensure sequencing (namely, variations

on locks) so it's just a question of how the program is written, not

whether it can be written at all.  This situation with AspectJ if-PCD

evaluation is the same: there are other ways to write the same thing

(and I would argue the other ways are much more clear).

Wes