Review: Review

Posted by Nathan Bruning on 12/11/2009 15:57, last updated on 12/11/2009 16:07 (Public)

AspectCOOL is an extension to a research language called COOL, providing aspect-oriented features. The main feature of the language is separate compilation of aspects and components (no weaving). This is made possible by adding method-invocation hooks to the runtime environment. Because an aspect needs explicit reference to the class it applies on, this research is nowhere near comparable to AspectJ in power and expressivity.

Introduction

In aspect-oriented programming, a new aspect-oriented language provides additional paradigms for some existing base language. This base language is called component language. The component language most often is a general-purpose programming language; for example, AspectJ [6] uses Java as component language. The aspect-oriented language can be a general-purpose aspect-oriented language, like AspectJ which is merely an extension to the Java language. Contrarily, a domain specific language could be devised to provide aspect functionality.

AspectCOOL is a general-purpose aspect-oriented language providing functionality for weaving aspects in programs written in the general-purpose (research) language COOL. The implementation of COOL was mainly an experiment to evaluate development using a language design tool called LISA [7].

Besides the basic aspect-oriented features that any aspect-oriented language provides, AspectCOOL provides separate compilation of aspects and components, which improves reusability: for example, aspects can be weaved in commercial off-the-shelf applications.

Summary

COOL is a general-purpose language specifically designed for studying oriented-oriented language design and implementations. For it to support separate compilation and the aspect-oriented extensions, the language was extended with dynamic (on-demand) module loading, method call interception, reflection (based on metaobject protocols [5]) and ``slots''.

Slots represent explicit code points at which advice (the semantics of an aspect) can weave in. A slot appears at statement level and consists of a name and a number of values: variables that are in (static) scope at the point of slot definition. An aspect can define a method which is executed with the given values for the parameters when execution reaches the point of slot definition. If no aspect defines behavior for a slot, it effectively turns into a no-operation.

The language strictly separates aspects in two parts: aspect classes and aspect applications. Aspect classes define the behavior of aspects, like advice in AspectJ. The aspect application part of an aspect defines the pointcut at which it must be weaved in the program. The reason for this separation is to prevent (compile-time) dependencies between the two: if an aspect’s behavior changes only the aspect code has to be recompiled, thereby avoiding the reapplication of all aspect weaving.

The AspectCOOL language defines four possible joinpoint types besides the explicit slots: before, enter, exit and after. All of these are method-invocation hooks. The first and last, before and after execute in the caller’s environment, while enter and exit execute from within the callee’s context.

An advice explicitly defines which class it can be applied to (which class it is able to advise). This aids the static type-checker in the presence of separate compilation. Inside advice code an implicit variable called self refers to the object instance to which the advice is applied. The type of this context-reference is then determined by the target class of the advice. This provides inclusion polymorphism at the aspect-level: the type-checker is able to locate all instance variables of the target class and its superclasses.

Slot advice does not reference any target class, but specifies all formal parameters it accepts, which is the only way communication can take place between the target code and the slot advice. Summarizing, an aspect is able to refer to context variables (self, the callee’s parameters), advice arguments and local advice variables.

The application part of aspects contain the pointcuts that define a mapping between joinpoints in target code and advice. Pointcuts are defined by wildcards, similar to AspectJ’s implementation, but use method transition (defined as a pair of methods) as the fundamental building block for defining joinpoints. For slot advices, matching an advice to a slot is easy, as both can be unambiguously identified by their qualified name: slots are unique within both the class and aspect namespace. Additional language constructs indicate how many instances of aspect classes are to be instantiated.

Having a mechanism for intercepting method invocation in the base language (COOL), the aspects before and after method calls are relatively easy to implement. An Aspect Manager is used to register all advices on joinpoints. Method execution starts by invoking the aspect manager, execution any registered before and enter advice. Following the callee method-call, the enter and exit advices are ran, having the possibility to intercept or change the return value. Similarly, a slot-statement in the component code is translated to some method of the Slot Manager, which checks its slot register and conditionally invokes slot aspects.

Evaluation

Besides the surprising choice of component language, the main differences between this approach and other aspect-oriented languages can be summarized as follows:

• Because the component language has method call interception, weaving in the aspects can be done as a simple preprocessor step opposed to the full compilation pipeline of AspectJ.
• Separation of advice body and pointcut definition removes the dependency of component code on aspect semantics.
• The explicit reference to the component language class on which an advice can be applied provides static type-safety and a full execution context in the advice body.

First, consider the modification of the component language to support features aiding aspect-oriented language. Similar approaches have also been proposed in [4, 2], both of which introduce an extension to the Java Virtual Machine to support AspectJ. The downside to modifying the runtime environment is that it requires modification to the entire toolset of the component language: compiler, debugger, development environments and the runtime system (virtual machine). Also, [8] notes that such approaches imply a tight coupling between the aspect language semantics and the runtime interpreter: the use of aspect-oriented features then fixes the choice of runtime system, preventing portability of the compiled application.

The separation of advice body and pointcut definitions was inspired by [1], but it appears that no implementation has yet resulted from this proposition. For changes in advice code, indeed separate compilation is made possible by this division of aspect parts. However, the issues with aspect-oriented languages and separate compilation are more extensive than just this issue. The article fails to evaluate how compilation proceeds when pointcuts change, when slots are added/removed or when slots change signature.

While any rationale is missing, the article claims that the explicit advice – class reference is essential for separate compilation. A similar proposal is presented in [3], in which the authors suggest (amongst other things) to make explicit which aspects involve which classesobservers. Their motives are mostly related to modular reasoning though. While enabling easier separation at the compilation stage, the approach taken in the currently reviewed article severely limits applicability of advice. Because a piece of advice must explicitly define the (one single) class on which it operates, the developer is deprived of any aspect reuse. This does seem unacceptable, even more given the article’s motivation: reuse is designated to be the main feature of AspectCOOL.

References

[1] A. Beugnard. How to make aspects re-usable, a proposition. In Lopes, C., Bergmans, L., Black, A. and Kendall, L. Proc. Aspect-Oriented Programming Workshop at ECOOP 99. [2] C. Bockisch, M. Haupt, M. Mezini, and K. Ostermann. Virtual machine support for dynamic join points. In Proceedings of the 3rd international conference on Aspect-oriented software development, pages 83-92. ACM New York, NY, USA, 2004. [3] C. Clifton and G.T. Leavens. Observers and assistants: A proposal for modular aspect-oriented reasoning. In FOAL 2002 Proceedings, page 33. [4] R.M. Golbeck, S. Davis, I. Naseer, I. Ostrovsky, and G. Kiczales. Lightweight virtual machine support for AspectJ. In Proceedings of the 7th international conference on Aspect-oriented software development, pages 180-190. ACM New York, NY, USA, 2008. [5] G. Kiczales, D.G. Bobrow, and J. des Rivieres. The art of the metaobject protocol. MIT press, 1999. [6] G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm, and W.G. Griswold. An overview of AspectJ. Lecture Notes in Computer Science, pages 327-353, 2001. [7] M. Mernik, M. Lenic, E. Avdicausevic, and V. Zumer. Lisa: An interactive environment for programming language development. In Compiler Construction: 11th International Conference, CC 2002 Held as Part of the Joint European Conferences on Theory and Practice of Software, ETAPS 2002, Grenoble, France, April 8-12, 2002: Proceedings, page 1. Springer Verlag, 2002. [8] H. Rajan, R. Dyer, Y. Hanna, and H. Narayanappa. Preserving separation of concerns through compilation. In Software Engineering Properties of Languages and Aspect Technologies (SPLAT 06), A workshop affliated with AOSD. 2006.