[aosd-discuss] invasives aspects --> answer to Marc

[Mira Mezini]

Hi Marc,

I have written some reactions to your email below. Sorry, this answer turned
out too long at the end... but, we need to go into the details of
argumentation when placing claims. 

Best, 
Mira

> Marc Eaddy writes:
>
> Let us consider only AspectJ-like (pointcut/advice) AOP languages.  Even 
> if they enable modular reasoning for the aspects themselves, they prevent 
> modular reasoning for the rest of the program.  These languages allow the 
> control flow of a program to be arbitrarily changed and private fields and

> methods to be accessed.  

Let me rephrase your last sentence first... Personally, I can't make much
sense of the phrase "languages allow the control flow of a program to
change..."

Languages allow programmers to model various concerns of a piece of software
and interactions between these concerns. So, I would rephrase what you are
saying to: AspectJ-like (pointcut/advice) AOP languages provide linguistic
means that enable the model of one concern to refer to relevant portions of
the control flow and/or data flow of the model of another concern. 

The rationale for doing so is to enable programmers to express EXPLICITLY
sophisticated interactions between crosscutting concerns. So, an AO
programmer that has to model the interaction between two concerns whose
control and data flow crosscut in non-obvious ways uses AO features as the
ones that you describe above. Now, I ask you to consider expressing the same
interaction without AOP. Will be able to express the interaction in a more
abstract way? I mean, will you be able to better abstract over irrelevant
implementation details in expressing the interaction? 

The ICSE paper by Gregor and myself [1] answers these questions with NO.
This is to say that the fine-grained interaction between the concerns under
consideration will have to be expressed in the non-AOP version, as well. It
is inherent to the existence of the crosscutting concerns that the
programmer wants to express. Compared to the AO version, the interaction in
the non-AO version will be expressed implicitly and in a less (or equal)
abstract way. It will be expressed by means of local variables used as flags
for keeping track of relevant control flows, by means of scattered method
calls following immediately after access to private fields or private method
calls, etc. 

The paper next shows by means of an example that this implicit and
non-abstract expression of the interaction makes more difficult to reason
modularly about BOTH crosscutting concerns - in that context, about both
point and lines (or what you might call the base program) and the display
updating protocol. This is one of the main points that the ICSE paper makes:
In the presence of crosscutting concerns NON AOP DOES NOT SUPPORT MODULAR
REASONING.  

Another point that the paper makes is that by making the interaction
explicit and by providing some means of quantification over control and data
flow (which may be used to express the interaction more abstractly) AOP
better supports modular reasoning. 

This said, more powerful means of referencing are needed to express the
interaction more abstractly and to also help with modular reasoning (I
strongly recommend also reading [2] and [3]). To see my point about more
abstract means of referencing, consider the following pseudo-aspect in the
AO language Alpha [3], which models points, lines, display and the update
updating protocol:

class Display {
  
  void draw() { ... }  

  void refresh() { ... }

  before set (O, F, _), 
         reachable (O, @this), 
         get (T1, _, O, F, _), 
         calls (T2, _, @this, draw, _), 
         cflow(T1, T2)
 { 
   refresh() 
  }

}   

class Point { 
  setX (int dx)
  {
    x+= dx; 
  }
 ...
}

class Line { ... }

Now, try to repeat your statements about "AO languages allow to change the
control flow ... of the program"... 
The pointcut-advice in Display is not talking about any private field access
or any control flow that belongs to some program: It is rather quantifying
about the execution space that all concerns share/contribute to. It is
saying: "whenever any field F of any object O, which is reachable on the
heap from this, is changed such that F was read at some point T1 within the
control flow of executing the draw method on this, display is refreshed".  

> Marc Eaddy writes:
>
> With some strategically placed 'around' advice, I can
> change a sorting program into a web server.  Without global reasoning, it
> would be impossible to predict the behavior of the program.  

Well, it is always possible to shoot yourself if you want to do so. 
In a non-AO language I can use a lot of local and global variables passed
around from remote places to simulate the effect of an around advice (at the
end all languages we are talking about are Turing complete). So, what's the
point? 

> Marc Eaddy writes:
>
> 	As pointed out in [1] and by others in this discussion, strictly
> speaking, polymorphism prevents modular reasoning.  These "lapses" in
> modular reasoning are considered acceptable because, in contrast to
> advice,
> polymophism is limited (only calls to virtual methods), restricted (only
> overridable methods), not oblivious (only these call sites), and intuitive
> (e.g., some kind of shape will draw itself when I call Shape.draw()).
> Modularity, evolvability, reusability, and modular reasoning would improve
> considerably if AOP languages were similarly restricted.
>
> 
> [1] Friedrich Steimann, "The Paradoxical Success of Aspect-Oriented
> Programming," OOPSLA '06
> http://portal.acm.org/ft_gateway.cfm?id=1167514&type=pdf&coll=GUIDE&dl=&CF
> ID
> =15151515&CFTOKEN=6184618

The claim about advice effects being global is not quite true. AO languages
do provide linguistic means to explicitly restrict the scope of the effect
of the aspect as well as what the aspect is allowed and not allowed. I can
use pointcut-advice of AO languages (i.e., quantification mechanisms) to
control the scope of the aspects. I can define a static scope (An example of
this kind of use is found in [4]. Also in [4] you can find an example of
expressing constraints on the behaviour of advice by using pointcut advice).


I can also define dynamic scopes, as it is possible with the deploy
construct of Caesarj-like languages [5]. To illustrate this case, let me
take an example that Leavens and Clifton have used to demonstrate the
problems of around related to behavioural subtyping. The example is about
points that can move arbitrary and points that can move only in one
direction. 

class Point {

  void move(int dx, int dy) {
    x+=dx;
    y+= dy;  
  }

  ...
}

class LimitedPoint extends Point {

  void move(int dx, int dy) {
     // check that dx and dy fulfil certain conditions and 
     // call super only if this is true
  } 
}

Now, this OO design in problematic since it does not obey to the Liskow
substitution principle: LimitedPoint is declared to be a subtype of Point
and can be used everywhere Point is expected while it is not a behavioural
subtype of Point. Client's assumptions about Points may get violated when
LimitedPoints are used instead. Similar issues occur if LimitedPoint was
implemented as an aspect that intercepts the calls to Point.move and uses
around to control the movement. This is true only for aspects declared with
unlimited scope. In CaesarJ, the client can explicitly decide to limit the
move of the points used in the context of the deploy block and only within
the thread that executes the deploy construct, being aware of the semantics
of the limitation (points can otherwise more freely):

class SomeClientOfPoints {

  void someMethod() {
    ...
    deploy{new LimitedPoint} { ... }
  }
}

Other deployment strategies are also possible.

To recap: AO languages provide linguistic means to enable programmers to
express restrictions when needed. What you require instead is to restrict
the linguistic means. 

I am not sure about this. This is as if one would forbid parts of a
language, just for the sake of avoiding the risk of misuse ... I am sure
everybody would be concerned about the freedom of speech :-)  


[1] G. Kiczales and M. Mezini. AOP and Modular Reasoning. ICSE 2005
[2] Lopes, Dourish, Lorenz, Lieberherr. Beyond AOP: Toward Naturalistic 
    Programming. OOPSLA Onward 2003
[3] Ostermann, Mezini, Bockisch. Expressive Pointcuts for Increased 
    Modularity. ECOOP 2005
[4] Griswold Sullivan, Song, Shonle, Tewari, Cai, Rajan. Modular Software 
    Design with Crosscutting Interfaces. IEEE Software, Feb. 2003
[5] Aracic, Gasiunas, Mezini, Ostermann. An Overview of CaesarJ. 
    Transactions on Aspect-Oriented Software Development.