Difference: Oct202010Review (1 vs. 5)

• The examples of infinite regression described early on in the paper all seem to have better possible solutions when considered individually:

• 2.1 (The Activity aspect that applies unintentionally to the Point#toString method): the key issue here is that the toString() method is incorrectly considered relevant to this aspect: simply excluding the toString() method from the relevant pointcut would be a simpler and more reliable solution. This reflects the fact that code has a lot of constraints and implicit rules that advice needs to be aware of in order to function correctly in general.
• 2.2 (Pointcut loops): I'm personally very uncomfortable with pointcut expressions including normal code, and would much rather not include pointcuts such as AspectJ's "if". There is also evidence that this is confusing for developers: http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg06195.html. Dealing with join points inside pointcut expressions feels like a superficial improvement on a much deeper problem.
• 2.3 (Control-flow exclusion not working with "around" advice): I would call this a bug in the "adviceexecution" pointcut, as the "proceed()" syntax is not a regular method call. It would be much more consistent to exclude code triggered by resuming from advice code from this pointcut.
• 2.4 (Visibility of aspects): interaction of aspects does indeed have to be controlled carefully, but aspect dependency management is part of languages like AspectJ already. The complexity of this convinces me that a single ordered dimension of visibility isn't adequate for a mature code base.
• 2.5 (Concurrency): again, this issue is avoided if the pointcut is customized to exclude toString() explicitly.

• The assumption that avoiding infinite regression is fundamentally safer is demonstrably false. As illustrated in the paper, unintentional interaction of aspects can lead to immediate failure in the form of infinite recursion, but non-interaction can lead to missing behaviour, which is much harder to identify. A security-related aspect, for example, could fail to track or access-control references to vulnerable functions simply because they have been refactored into aspects!

• The fact that the proposed solution is presented in Scheme notation and semantics makes it difficult to relate the solution back to the examples of the problem from Section 2. This runs deeper than mere reader understanding, in fact: because the solution is given in a language where pointcuts and advice are treated as first-class values, and declaring aspects is performed inline with normal execution rather than statically, I'm not convinced it is actually reasonable to apply execution levels properly to AOP languages like AspectJ.

• Is infinite regression of advice fundamentally harder to debug, understand and correct than classic infinite recursion or looping in non-AOP code?

• Are there other potential pointcut varieties needed to avoid all cases of infinite regression?

• What was the intended benefit of adding the "if" pointcut to AspectJ, when it should be equivalent to wrapping the advice body in the same if condition?

• 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 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.

• 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.

• 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?

• 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 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.

• 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?

http://portal.acm.org/citation.cfm?doid=1739230.1739236

Robin's Review

Problem

Contributions

Weaknesses

Questions

Belief

Nick's Review

Problem

Contributions

Weaknesses

Questions

Belief