Re: [aspectj-dev] Aspect reentrancy

[Gregor Kiczales <gregor@xxxxxxxxx>]

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