[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-dev] Aspect reentrancy
|
Hi Oege,
Thanks for this brief reply!
As you rightly
point out, that's not what ajc and abc implement, for efficiency
reasons, as otherwise the compiler would need to check whether
any joinpoint is in the cflow of an if-pointcut evaluation.
The semantics of Wand et al., as far as I understand, does not
consider if pointcuts. So yes, if you have no if pointcuts, this means
your aspects can't really 'interact' with the application in their
pointcuts (beyond doing matching stuff like type checks), so I
certainly like the idea of not exposing join points that may occur
during pointcut matching.
But as soon as you have if pointcuts, this does not hold. So you have
to make a choice.
Is it correct to have a non-consistent semantics for efficiency reasons?
I personally don't think so.
There are lots of other difficulties that arise from having
arbitrary Java expressions in if pointcuts, see for instance
https://bugs.eclipse.org/bugs/show_bug.cgi?id=61569
Personally I think the right solution would be to forbid
complex expressions in if-pointcuts.
This relates to having side-effects in if pointcuts, and the
associated problem with evaluation order. Jim suggesting that "we
should state explicitly that if pcd's SHOULD NOT have side-effects as
a style guide". Whether his position is the correct or not, I guess
this is much different from the example I've shown.
In which sense is, in an OO program, the expression "p.getX()" a
'complex expression'?
I don't get it. It's just a simple method call, with no side effects.
If you would be in Smalltalk, there is nothing you could do that would
not be a method call...
I do not think your proposal of making ifs in advice and in
pointcuts equivalent is a good plan. For one thing, partial
evaluation of pointcut matching will have to be scrapped,
disabling almost all compiler optimisations for AspectJ.
For instance you could add "if(0 !=1)" to your example
pointcut. Now under your semantics, I would still have to
generate the joinpoint for the other if, or would you
make it nondeterministic whether that joinpoint occurs
or not?
Well, what would happen if you write your code in the advice:
when you have two ifs, and the first fails, the second is not
evaluated. Why not taking the same approach here? I don't see how that
affects partial evaluation of pointcut matching.
I am not claiming that there are no issues raised by a proper semantic
treatment of if pointcuts. Just that the current situation seems too
awkward semantically. And I'm sure that with a good semantics, there
are a lot of smart guys doing advanced optimization stuff that will
come up with good ways to do correct things efficiently.
Cheers,
-- Éric
