| | É. 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 |
| | 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 clear 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.
|
>
> |
- 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 |
|
<
< |
- The switch from AspectJ examples early in the paper to a Scheme-like implementation later on is disconcerting. It's not clear to me why this shift is necessary.
- 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 also seems to contradict the goal of making the default behaviour safe for the average programmer.
|
>
> |
- 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 seems like it would 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 AspectML, 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 |
|
<
< |
- How big is the problem of advice loops and pointcut loops? Can we work around it just by being careful about the code we put in to pointcuts and advice (and by defining our pointcuts carefully)?
- The proposed default behavior is for pointcuts and advice to be evaluated at level 1 -- i.e. not "visible" to aspects deployed below level 2. Is this a reasonable default -- is the average AOP programmer likely to find this natural, or surprising?
- The adv-shift-up/down functions 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?
|
>
> |
- 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 paper. It lays out the problem clearly, and makes a convincing case that current workarounds are fundamentally flawed. The construct of execution level seems a pretty natural way of resolving the tension. Questions remain for me around the complexity of level shifting within a given advice, and the usability of the level-capturing lambda. |
>
> | 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 AspectML. |
| | |
Copyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.