Figure 4 - uploaded by Éric Tanter
Content may be subject to copyright.
Source publication
Aspect languages provide different mechanisms to control when an aspect should apply based on properties of the execution context. They however fail to explicitly identify and cleanly capture a property as basic as that of reentrancy. As a result, aspect developers have to resort to low-level and complex pointcut descriptions that are error prone a...
Similar publications
Państwowe fundusze majątkowe (ang. Sovereign Wealth Funds, SWF) to podmioty tworzone przez kraje dysponujące trwałymi rezerwami dewizowymi, jakie mają być zarządzane w sposób długookresowy i produktywny. SWF, prócz priorytetów związanych z efektywnością inwestycyjną, najczęściej realizują dodatkowo różne cele społeczne i polityczne. Celem niniejsze...
University of Surrey, UK © eceee and the authors 2018 eceee's energy sufficiency project is funded by the KR Foundation. It aims at exploring how we can live well, within the limits. Learn more at energysufficiency.org.
Citations
... One direction, we are working on, is to simplify the use of the current AspectJ-like features with AspectJML. For instance, to prevent infinitely recursive advice application [5], as can happen in with AspectJ. Another direction, we intend to add in AspectJML is the notion of slicing [41]; this will be useful since in current Aspec-tJML we do not support the open classes mechanism, also known as inter-type declarations in AspectJ [16]. ...
Many programs have crosscutting concerns for which neither procedural nor object-oriented programming adequately modularize, which has led to the idea of aspect-oriented programming (AOP). However, AOP has not found favor with the programming languages community due to a belief that AOP breaks classical modularity and modular reasoning. We propose a new AOP programming model that enables both crosscutting modularity and modular reasoning. This model is implemented by AspectJML, a general-purpose aspect-oriented extension to Java. It supports modular crosscutting concerns using key object-oriented mechanisms, such as hierarchical structure, and allows reasoning that scales to ever-larger programs.
... Controlling aspect reentrancy. In previous work, we draw an analysis of the two first issues of the previous section, under the umbrella term of aspect reentrancy [45]. We distinguish between base-triggered reentrancy (caused when an aspect matches join points that are produced by e.g. a recursive base program, not discussed here), advice-triggered reentrancy (Section 2.1), and pointcut-triggered reentrancy (Section 2.2). ...
... Moreover, the two initial approaches used in reflective architectures, ad-hoc checks and special primitive mechanisms, are also found in AOP. Explicit control-flow checks in AspectJ, or the default reentrancy control we proposed previously [45], are examples of the former. AspectScheme's app/prim and AspectML's disable are examples of the latter. ...
... In AspectScript, pointcuts and advices are standard JavaScript functions-therefore, levels are crucial to avoid infinite regression. In addition to execution levels, the language supports reentrancy control [45]-which ensures that shifting down computation cannot provoke loops-and expressive scoping of aspects using scoping strategies [46,47]. Aspect weaving in AspectScript is similar to aspect weaving in LAScheme. ...
In aspect-oriented programming (AOP) languages, advice evaluation is usually considered as part of the base program evaluation. This is also the case for certain pointcuts, such as if pointcuts in AspectJ, or simply all pointcuts in higher-order aspect languages like AspectScheme. While viewing aspects as part of base level computation clearly distinguishes AOP from reflection, it also comes at a price: because aspects observe base level computation, evaluating pointcuts and advice at the base level can trigger infinite regression. To avoid these pitfalls, aspect languages propose ad-hoc mechanisms, which increase the complexity for programmers while being insufficient in many cases. After shedding light on the many facets of the issue, this paper proposes to clarify the situation by introducing levels of execution in the programming language, thereby allowing aspects to observe and run at specific, possibly different, levels. We adopt a defensive default that avoids infinite regression, and gives advanced programmers the means to override this default using level-shifting operators. We then study execution levels both in practice and in theory. First, we study the relevance of the issues addressed by execution levels in existing aspect-oriented programs. We then formalize the semantics of execution levels and prove that the default semantics is indeed free of a certain form of infinite regression, which we call aspect loops. Finally, we report on existing implementations of execution levels for aspect-oriented extensions of Scheme, JavaScript and Java, discussing their implementation techniques and current applications.
... However, we consider that pointcuts and advices are executed by app/prim in "sandboxes" (e.g., by the base language interpreter) where no aspect can match, thereby avoiding aspect reentrancy issues. For a general discussion about reentrancy issues with aspects, in particular with first-class pointcuts and advices, we refer the reader to the work of Tanter [24,27]. ...
Dynamic deployment of aspects brings greater flexibility and reuse potential, but requires a proper means for scoping aspects. Scoping issues are particularly crucial in a distributed context: adequate treatment of distributed scoping is necessary to enable the propagation of aspect instances across host boundaries and to avoid inconsistencies due to unintentional spreading of data and computations in a distributed system. We motivate the need for expressive scoping of dynamically-deployed distributed aspects by an analysis of the deficiencies of current approaches for distributed aspects. Extending recent work on scoping strategies for non-distributed aspects, we then introduce a set of high-level strategies for specifying locality of aspect propagation and activation, and illustrate the corresponding gain in expressiveness. We present the operational semantics of our proposal using Scheme interpreters, first introducing a model of distributed aspects that covers the range of current proposals, and then extending it with dynamic aspect deployment and scoping strategies. This work shows that, given some extensions to their original execution model, scoping strategies are directly applicable to the expressive scoping of distributed aspects.
... Also, AspectScript integrates scoping strategies [30, 31] for proper control over the scope of dynamicallydeployed aspects. In addition, AspectScript avoid issues of infinite loops due to aspect reentrancy [29]. Finally, AspectScript not only supports implicitly-generated join points following the language model, but also provides the possibility to define custom join points triggered explicitly, as in Ptolemy [26] . ...
... In fact, while this issue of aspect reentrancy is exacerbated in a higher-order aspect language like AspectScript, it is latent in any aspect language 10 . Some mechanism must be provided to avoid aspects potentially matching join points triggered by their own execution [10, 29]. Limitations of current solutions. ...
... Current AspectJ patterns to address these issues are similar to disable: adding a control-flow condition to pointcuts such that join points occurring in the dynamic extent of advice execution are ruled out [10]. The AspectJ pattern however does not work in the case of reentrancy caused by if pointcuts [29]. As argued extensively elsewhere [32], relying on control flow checks to avoid reentrancy is flawed for several reasons. ...
JavaScript is widely used to build increasingly complex Web applications. Unsurprisingly, these applications need to address cross-cutting concerns. Therefore support for aspect-oriented programming is crucial to preserve proper modularity. However, there is no aspect-oriented extension of JavaScript that fully embraces the characterizing features of that language: dynamic prototype-based programming with higher-order functions. In this paper, we present AspectScript, a full-fledged AOP extension of JavaScript that adopts higher-order programming and dynamicity as its core design principles. In AspectScript, pointcuts and advices are standard JavaScript functions, bringing the benefits of higher-order programming patterns to define aspects. In addition, AspectScript integrates a number of state-of-the-art AOP features like dynamic aspect deployment with scoping strategies, and user-defined quantified events. We illustrate AspectScript in action with several practical examples from the realm of client Web applications, and report on its current implementation. AspectScript is a practical extension that provides better modularity support to build Web applications, and that will eventually make it possible to empirically validate the benefits brought by advanced aspect language mechanisms in an evergrowing application domain.
Aspect-oriented programming (AOP) is a programming paradigm to localize and modularize the concerns that tend to be tangled and scattered across traditional programming modules, like functions or classes.
Such concerns are known as crosscutting concerns and aspect-oriented languages propose to encapsulate them in modules called aspects. Because each crosscutting concern implemented in an aspect is separated from the other concerns, AOP improves reusability, readability, and maintainability of code.
While it improves separation of concerns, AOP suffers from well-known composition issues. Aspects developed in isolation may indeed interact with each other in ways that were not expected by the programmers and therefore lead to a program that does not meet its requirements. Without appropriate tools,
undesired aspect interactions must be identified by reading code in order to gain global knowledge of the program and understand where and how aspects interact. Then, if the aspect language does not offer the needed support, these interactions must be resolved by invasively changing the code of the conflicting aspects to
make them work together. Neither one of these solutions are acceptable since global knowledge as well as invasive and composition-specific modifications are exactly what separation of concerns seeks to avoid.
In this dissertation we show that the existing approaches to compose aspects are not entirely satisfying either with respect to separation of concerns. These approaches either rely on global knowledge and invasive modifications, which is problematic, or lack genericity and/or expressivity, which means that code reading/code modification may still be required for the aspect interactions they cannot handle.
To properly detect and resolve aspect interactions we propose a novel approach that is based on AOP itself. Since aspect composition is a concern that, by definition, crosscuts the aspects, it indeed makes sense to expect that a technique to improve the separation of crosscutting concerns such as AOP is well-suited for the task. The resulting mechanism is based on reflection principles and is called reflective AOP.
The main difference between “regular” AOP and reflective AOP lies in the parts of the system they address. While traditional AOP aims at modularizing the concerns that crosscut the base system, reflective AOP offers the possibility to handle the concerns that crosscut the aspects themselves. This is achieved by incorporating new kinds of joinpoints, pointcuts and advice into the aspect language. These new elements, which form what we call a meta joinpoint model, are dedicated to the aspect level and enable programmers to reason about and act upon the semantics of aspects at runtime. As validated on numerous examples of aspect composition, having a well-designed and principled meta joinpoint model makes it possible to deal with both the detection and the resolution of composition issues in a way that preserves the separation of concerns principle. These examples are illustrated using Phase, our prototype reflective AOP language.
Dynamic deployment of aspects brings greater flexibility and reuse potential, but requires proper means for scoping aspects. Scop- ing issues are particularly crucial in a distributed context: adequate treatment of distributed scoping is necessary to enable the propaga- tion of aspect instances across host boundaries and to avoid incon- sistencies due to unintentional spreading of data and computations in a distributed system. We motivate the need for expressive scoping of dynamically- deployed distributed aspects by an analysis of the deficiencies of current approaches for distributed aspects. Extending recent work on deployment strategies for non-distributed aspects, we then intro- duce a set of high-level strategies for specifying locality of aspect propagation and activation, and illustrate the corresponding gain in expressiveness. We present the operational semantics of our pro- posal using Scheme interpreters, first introducing a model of dis- tributed aspects that covers the range of current proposals, and then extending it with dynamic aspect deployment. This work shows that, given some extensions to their original execution model, de- ployment strategies are directly applicable to the expressive scop- ing of distributed aspects.
In aspect-oriented programming languages, advice evaluation is usually considered as part of the base program evaluation. This is also the case for certain pointcuts, such as if pointcuts in AspectJ, or simply all pointcuts in higher-order aspect languages like AspectScheme. While viewing aspects as part of base level computation clearly distinguishes AOP from reflection, it also comes at a price: because aspects observe base level computation, evaluating pointcuts and advice at the base level can trigger infinite regression. To avoid these pitfalls, aspect languages propose ad-hoc mechanisms, which increase the complexity for programmers while being insufficient in many cases. After shedding light on the many facets of the issue, this paper proposes to clarify the situation by introducing levels of execution in the programming language, thereby allowing aspects to observe and run at specific, possibly different, levels. We adopt a defensive default that avoids infinite regression in all cases, and give advanced programmers the means to override this default using level shifting operators. We formalize the semantics of our proposal, and provide an implementation. This work recognizes that different aspects differ in their intended nature, and shows that structuring execution contexts helps tame the power of aspects and metaprogramming.
