[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