[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] If pointcut and side effects
|
Is it correct then to say that in the absence of if pointcuts with
side effects, the evaluation order does not matter? No other pointcut
than if can have side effects?
I understand you wonder where I want to go with this :) I'm doing
analysis of control and data dependencies in relation to faults in
pointcuts, and in such a scenario it could be useful to be able to
state things about control and data dependencies between the
different conditions of a pointcut. But relying on implementation
decisions is probably a bad thing anyway.
Jon
On May 31, 2006, at 9:00 PM, Eric Bodden wrote:
Why was this decision made? For better/faster implementation? From a
usability point of view, one would certainly like to have control
over
the evaluation order (especially since AspectJ is an augmentation of
Java where boolean expressions have a defined order).
Using the same "lazy/jumpingcode" evaluation technique for
pointcuts as
you know it from Boolean expressions would not make much sense,
e.g. for
the following reason. Imagine the following three pointcuts:
pointcut p1(int i): args(i) && if(i>2) && call(* Foo.*(int));
pointcut p1(int i): if(i>2) && args(i) && call(* Foo.*(int));
pointcut p2(int i): call(* Foo.*(int)) && args(i) && if(i>2);
I think we both agree that those two pointcuts should always match the
same joinpoints. If you now evaluated p1 as you suggest, that means
that
first at *any* method with an int argument we have to bind this
argument, check if it's >2 and then last but not least we check if
this
method is actually in class Foo at all. Would make no sense, would it?
Just imagine the runtime overhead. Pointcut p2 would be even worse:
You
would access i before having it bound! Consequently, any sensible
compiler will generate the residues in the order depicted by pointcut
p3. This would lead to dynamic residues only be inserted in inside the
class Foo and with the appropriate signature. Also, values being
accessed by if pointcuts will be bound, since if pointcuts are
moved to
the end.
Are there any simple rules that can be stated about evaluation order
given the current (eclipse) implementation of AspectJ? (I know I
shouldn't rely on them but I'm curious)
No, and there should not be any rules. It's an *if* pointcut, meant to
evaluate a sideeffect-free Boolean expression and for nothing else.
I am
really wondering what you are trying to achieve by this technique. I
never found a need for such a thing.
Eric
--
Eric Bodden
Sable Research Group, McGill University
Montreal, Canada
http://bodden.de
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
