(r4) Oct202010Review < SPL

Tags: view all tags
É. Tanter, “Execution levels for aspect-oriented programming,” Proceedings of the 9th International Conference on Aspect-Oriented Software Development,  Rennes and Saint-Malo, France: ACM, 2010, pp. 37-48. DOI = http://portal.acm.org/citation.cfm?doid=1739230.1739236

---++ Robin's Review

---+++ Problem 

---+++ Contributions

---+++ Weaknesses

---+++ Questions

---+++ Belief

---++ Nick's Review

---+++ Problem 
The paper describes a problem with existing AOP implementations.  Advice contains base level code -- i.e. code which may trigger pointcuts.  Pointcuts were originally intended to be "meta" constructs, but, in practice, their definitions can also contain base level code.  The consequence is the possibility of infinite regression through pointcut loops or advice loops.  Existing workarounds rely on the cflow pointcut, which can disable advice based on the calling context.  The creation of a "pointcut execution pointcut" would allow this workaround to apply to pointcut loops as well.  However, this workaround cannot deal with the case of "around" advice.  It also fails to handle variable aspect visibility _within the same advice_, and advice which delegates execution to another thread.
---+++ Contributions
   * One contribution seems to be laying out the different dimensions of the problem, and showing that control-flow-based approaches cannot address "around" advice, variable aspect visibility, and concurrency issues.
   * The other contribution is a plausible path forward.  The notion of an execution level is easy to grasp and seems to mesh with basic intuitions about how pointcut evaluation and advice execution should work.
---+++ Weaknesses
   * It's a bit unsatisfying that, in order to deal with the case where advice runs in a separate thread, a new lambda abstraction has to be introduced.  This seems to contradict the goal of making the default behaviour safe for the average programmer.
   * The paper mentions the possibility of deploying aspects at higher levels, so that they can monitor aspects below them.  A limitation of this seems to be that the user must deploy the aspect at all the levels they wish to monitor.  This would likely be very tricky to manage.  Who deploys the aspects?  Do they know which levels a given aspect should be deployed at?  My guess is that the more popular way to expose aspect execution would be through level shifting.
   * The paper briefly mentions the "disable" primitive of <noautolink>AspectML</noautolink>, which can turn off pointcuts during evaluation of an expression.  With execution levels, if we assume that most aspects will run at level 1, and exposing the execution of these aspects will be done through level shifting, the code and behaviour starts to look very similar to code using the disable primitive.  The paper does not devote enough attention to how the two approaches differ, and what advantages come with execution levels.
---+++ Questions
   * The proposed default behavior is for pointcuts and advice to be evaluated at level 1 -- i.e. not "visible" to aspects deployed by code at level 0.  Is this a reasonable default -- is the average AOP programmer likely to find this natural?
   * The up/down operators allow the implementor of the advice to decide whether other aspects get to "see" a given part of the advice.  Is it correct to leave this decision entirely up to the one writing the advice?
   * Is the proxy-based AOP approach of Spring vulnerable to the issues described in this paper?
---+++ Belief
I think this is a useful, but flawed paper.  It lays out the problem clearly, and makes a convincing case that current workarounds are not sufficient.  On the surface, the construct of execution level seems a pretty natural way of resolving the tension.  For practical purposes, however, it is not clear how much this improves on the "disable" primitive proposed for <noautolink>AspectML</noautolink>.
Topic revision: r4 - 2010-10-19 - NickSawadsky