Section 2.4. QUANTIFICATION

2.4. QUANTIFICATION

AOP is thus the desire to make programming statements of the form

In programs P, whenever condition C arises, perform action A. (1)

over "conventionally" coded programs P. This suggests three major choice dimensions for the designer and implementer of an AOP system:

• Quantification. What kinds of conditions can we specify?

• Interface. How do the actions interact with the programs and with each other?

• Weaving. How will the system arrange to intermix the execution of the programs with the actions?

In an AOP system, we make quantified statements about which code is to execute in which circumstances. We note that there has periodically appeared in the AOP literature discussions of "symmetric" and "asymmetric" AOP systems. In symmetric languages, all program elements are equal, and following the directions of a composition language, the equal pieces are composed together into a whole. Hyper/J [37] is the canonical example of a symmetric language. An asymmetric language divides the world into a base program and aspects. We are agnostic to this religious divide, merely noting that if one is allowed to quantify over one's aspects, the two can be understood to be equivalent.

Over what can our AOP systems let us to quantify? Broadly, we can quantify over the static structure of the system and over its dynamic behavior.

2.4.1. Static Quantification

The static structure is the program as text. Two common views of program text are in terms of the public interfaces of the program (typically methods, but occasionally also public variables) and the complete structure of the programtypically, the parsed-program as abstract syntax tree (though occasionally the object code [8]).

Black-box AOP systems quantify over the public interface of components like functions and object methods. Examples of black-box systems include Composition-Filters [2], synchronization advice [25], aspect moderators [9], and OIF [18]. A simple implementation mechanism for black-box AOP is to wrap components with the aspect behavior.

Clear-box AOP systems allow quantification over the internal (parsed) structure of components. Examples of such systems include AspectJ, which allows (among other things) quantifying over both the calling and accepting calls in subprograms [27, 28], Hyper/J, whose composition rules allow quantifying over elements such as the interpretation of variables and methods within modules [37], meta-interpreter-based systems, where the process of program interpretation is modified to run aspects [3, 38], and transformation systems, where actual object, intermediate, or source code is transformed to include aspect behavior [8, 12, 20, 22, 29].

A given AOP system will present a quantification language that may be as simple as just allowing aspect decoration of subprogram calls or complex enough to represent pattern matching on the abstract syntax tree or compiled structure of the program. Understood this way, a clear-box AOP system could allow static quantifications such as "add a print statement to show the new value of any assignment to a variable within the body of a while loop if the variable occurs in the test of the while loop."

Clear-box and black-box techniques each have advantages and disadvantages. Clear-box techniques require source or object code. They provide access to all the (static) nuances of the program. They can straightforwardly implement "caller-side" aspects (aspects associated with the calling environment of a subprogram invocation). Black-box techniques are typically easier to implement. (In environments like Lisp, where calls are ordinarily routed through a modifiable function symbol, black-box techniques can be downright trivial.) Black-box techniques can also be used on components where the source code is lacking.

Because black-box techniques can't quantify over anything besides a program's interface, clear-box techniques are especially useful for debugging. For example, a clear-box system could implement a concern like a statement-execution counting profiler, or writing to a log file on every update of a variable whose name starts with "log." However, black-box techniques are more likely to produce reusable and maintainable aspectsan aspect tied to the code of a module can easily slip into dependence on the coding tricks of that module. Interfaces imply contracts.

Clear-box techniques are more difficult to implement, as they usually imply developing a major fraction of a compiler. A typical clear-box implementation of structural quantification needs to obtain a parsed version of the underlying program, run transformation rules realizing the quantified aspects over that abstract syntax tree, and output the resulting tree back in the source language for processing by the conventional language compiler. That can be a lot of work.

2.4.2. Dynamic Quantification

Dynamic quantification is tying the aspect behavior to something happening at run-time. Examples of such occasions include:

• The raising of an exception.

• The call of a subprogram X within the temporal scope of a call of Y. (The call of X within the context of Y problem is an instance of the "jumping aspect" problem [2].)

• The size of the call stack exceeding some value.

• Some pattern of more primitive events in the history of the program being matched; for example, after the "try password" routine has failed five times with no intervening successes.

• The swapping of the running thread.

The abstractions most programming languages present about the structure and execution of a program are only a subset of the possible available abstractions: Scheme allows a programmer to capture the "current context" and reinvoke the current behavior. C programmers glibly rummage around on the stack, content in the knowledge that the pattern of procedure calls is straightforwardly recognizable so long as the machine and compiler remain constant. 3-Lisp and similar reflective systems allow the programmer access to the interpreter's state [13]. Elephant allows reference to previous variable values [35]. The ability to program with respect to such properties is an ingredient of programming language design. Even if such elements are absent in the underlying language, an aspect language may still allow quantification over them. Filman and Havelund present a more detailed discussion of the possibility of dynamic AOP mechanisms [20]; a recent implementation of an AOP system based on event response is [14].