[aosd-discuss] motivation for call vs execution pointcut/join point distinction

[Renaud Pawlak]

Rickard Öberg wrote:

> Alexandre Vasseur wrote:
> 
>> Last time I was discussing AOP concepts with some C guy, I came
>> accross a suprising feeling. Why do we need to distinguish call from
>> execution join point in AOP implementations like AspectJ, AspectWerkz
>> etc. ? Wouldn't that be tied to the view we have coming from source
>> level / bytecode level instead of general method dispatching ?
> 
> 
> Well, don't know about the theoretical side of this (and am not sure I 
> care either), but personally I simply have a bunch of usecases where I 
> need to distinguish between them. For example, if I have a locking 
> aspect I only want it to apply on "call" and not "execution" (no point 
> in locking within an object since by then it is already locked). And 
> sometimes I *do* want "call" and "execution" to be the same (e.g. 
> transaction demarcation). As simple as that.


Ummm, I don't think that this problem is as simple as it seems. 
Christopher's email gives really good hints about the kind of problems 
that may occur when reasoning in terms of calls and executions. Of 
course, I do agree that these problems may not be relevant in the 
context of a given aspect or framework.

I personally came to the conclusion that, when people use "calls", they 
most of the time mean "execution within a given method control flow". 
Indeed, a call advice has *most of the time* the same effect than the 
combination of a cflow (on the method which performs the call) and an 
execution advice (on the called method execution).

For instance (I show in [] where the aspect impacts the code):

class C {

    void m1() {
       [call(m2)]
       m2();
    }

    void m2() { ... }

}

Is *most of the time* equivalent to:

class C {

    [start cflow c1]
    void m1() {
       m2();
    }

    [execution(m2) within cflow c1]
    void m2() { ... }

}

The second solution may seem more complicated. It is however much better 
regarding two criteria:

1. cflow based solutions are more robust: when refactoring, some 
indirections can be made that invalidate the call solution (and not the 
cflow one).

For example:

class C {

    void m1() {
       decoratingMethod();
    }

    void decoratingMethod() {
      ...
      m2();
    }

    void m2() { ... }

}

Will still work with the cflow solutions. The reason why it works better 
is that when the programmer designed the aspect, s/he meant "execution 
of m2 within the m1 cflow", and not "calls of m2 within m1".

2. cflow based solutions are more flexible regarding aspect composition. 
  Indeed, if you only use cflow + executions in your programs, you will 
be able to totally control the ordering of the aspects on your execution 
points. Thus, if you want to apply an aspect after another one, it is 
always possible. On the other hand, since call advices are always (I 
mean most of the time ;) applied before the executions, it is not 
possible to cleanly control the ordering of the aspects. This may lead 
to real composition and evolution problems -- especially when the 
call/execution semantics is tricky as mentionned by Christopher.

These two points made me realize that "calling-side" advising was 
dangerous for long-term software evolution and I personally avoid it as 
much as I can. I really think that call advising is harmful. It may be 
really useful in some cases, when it is really what the programmer wants 
to do, but it is not *most of the time*. Btw, if somebody has examples 
of call advice wich cannot be replaced by a cflow+execution solution, 
I'd be interested to look at it. Note that obvious examples are 
communication aspects. But they are most of the time implemented through 
proxies. In these cases, you may just want to advice the execution of 
the proxy...

Cheers,
/Renaud


> 
> /Rickard
> 
> 
> __________________________________________________
> AOSD Discuss mailing list    -    discuss at aosd.net
> To unsubscribe go to http://aosd.net
> 
> 


-- 
Renaud Pawlak
Researcher
INRIA Futurs - Projet JACQUARD
LIFL, UMR CNRS 8022, Equipe GOAL - Bâtiment M3
59655 Villeneuve d'Ascq Cédex - FRANCE
Phone:  (+33) 328 778579
Cell:   (+33) 662 001919
Fax:    (+33) 328 778537
Emails: renaud.pawlak at inria.fr / pawlak at lifl.fr
WWW:    http://www.lifl.fr/~pawlak