Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-dev] Aspect reentrancy 
Hi,
Indeed, having a means to match join points arising from an if body would be the least to do. Because then the general idiom ! cflow(within(A)) would avoid the problem of pointcut-based reentrancy.
What we propose in the previously-mentioned paper is to have a join point kind for pointcut matching, parametrized by the pointcut, so that we can discriminate at a finer-grained level. Same for advice execution, which in AspectJ is too general (it matches any advice execution).
Finally, what we suggest is that having by default a semantics where reentrant join points are not matched (although visible to other aspects), would simplify a lot the definition of pointcuts. As of now, you can see how many times people have to write (or simply forget and then ask for help) the typical idioms to avoid matching reentrant join points.
Also, our notion of reentrancy makes it possible to express scoped reentrancy (for instance something like a per-instance cflowbelow), which is otherwise quite cumbersome to define (one has to use AspectJ to implement his own per-object cflow stack). 

-- Éric


On Apr 14, 2008, at 14:58 , Gregor Kiczales wrote:

Hmmm...

Consider the following workaround...
Wrap the body of the if pointcut in a helper method. Then your p.getX will 
be in a lexical scope that you can guard with !within( .... ).
Now you have reduced this case to the ordinary problems with if bodies, namely that you can't be sure when they will run, they shouldn't have side 
effects etc.

Clearly the documented language semantics could be equivalent to the
workaround -- !within(enclosing-type) could match the join points arising 
from an if body.
But you'd still have to live with the other strange properties of if. Is 
that what we want?



On 4/14/08 7:48 AM, "Eric Tanter" <etanter@xxxxxxxxxxxxx> wrote:





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_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev



_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev

Back to the top