[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] If pointcut and side effects

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();
public void m(C1 c) {

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) {

around in
around out


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

what interest is it to check it if
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).