Separation of concerns for procedural and object-oriented programming languages was based on separating a system into modules. In aspect-oriented languages cross-cutting and reusable aspects are being identified and treated as individual modules. At compile-time the aspect weaver destroys the modularity by outputting base code tangled with aspect code. Because of this, incremental compilation is troublesome and discrepancies between the system views at source code and target code level. The paper introduces an interface between the aspect-weaving compiler and the target runtime (interpreter). The approach in essence compares very well to the concept of delayed weaving.
Posted by Nathan Bruning on 12/01/2010 14:16 (Public)[Read more]
This article discusses the merits of modular reasoning and why aspect oriented programming in its current form troubles modular reasoning. The authors propose a classification of aspects in observers and assistants. Observers do not affect behavior of a module and therefore do not have to be included in functional descriptions. Assistants do affect the behavior, but by proposing syntax that (statically) identifies which aspects are applied on which modules, modular reasoning is still feasible. This review points out some major problems with this approach, mainly the loss of obliviousness: a necessity of good aspect-oriented designs, according to other authors.
Posted by Nathan Bruning on 12/01/2010 13:59, last updated on 12/01/2010 13:59 (Public)[Read more]
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.
Posted by Nathan Bruning on 12/11/2009 15:57, last updated on 12/11/2009 16:07 (Public)[Read more]
The paper describes the inner workings of the weaving-process in the AspectJ compiler. Basically, jointpoints are matched to pointcuts. Java bytecode instructions are then added to execute the advice at that place. Arguments are given for not inlining the aspect code, followed by a detailed performance evaluation of both the compile-time and the run-time impact. The performance analysis is concluded with the remark that 22% of run-time performance penalty is not a problem for modern applications, which is surely debatable. Also, the paper fails to explain the separate compilation features of AspectJ which remain concealed and doubtful.
Posted by Nathan Bruning on 12/11/2009 16:05, last updated on 12/11/2009 16:06 (Public)[Read more]