Section 5.6. THE ESSENCE OF AOP

5.6. THE ESSENCE OF AOP

What is it about Aspects that makes them both attractive to researchers and useful to practitioners? And where can we go from here? I haven't worked in AOP for a couple of years, but being as fascinated by languages as I was then, it's very interesting to try to answer these questions.

First of all, programming languages are incredibly restrictive programming systems. They all have one fundamental weakness. They emphasize the fact that they are a means to define computational processes, and they ignore the fact that they are a means for humans to write and read computational processes. Humans don't think using any of the existing programming languages. Even if we do, we certainly haven't been writing down structured ideas for thousands of years using those languages. We have been using natural languages. That has worked out quite well. Natural languages are as general purpose as languages can get. They contain an extremely rich and diverse set of constructs that allow us to write down an enormous amount of ideas concisely in modular ways that can be easily understood by others.

Computer systems, of course, are different. I am not suggesting that programming languages should have a natural language interface. That was suggested a long time ago (Sammet [40], Ballard, and Biemann [4]) and it has been done before (Hypertalk [49] and NaturalJava [38]); the result is always limited or dubious. However, I am suggesting that programming language designers should pay more attention to the way natural languages work and the way we structure ideas with them. This is related to what I think is the major contribution of AOP to the next generation of programming systems.

Take tracing, for example. When we think of tracing, we formulate something like this: "For all methods, call TRace.in before they start executing and trace.out after they finish executing." However, all programming languages will force us to transform this sentence into something like this: "In method A, call TRace.in; . . . call trace.out; return. In method B, etc." So what is it about the first representation of the intention that's better than the second, and how does the natural language help? In this case, it's the references to "all methods," "before . . . executing," and "after . . . executing." That's the power of AspectJ: it supports a richer set of structural and temporal referencing that follows what we have in natural languages. AspectJ does it in a way that seems to be very useful for practitioners: It allows the encapsulation of these forms in modules that can be added to or removed from the applications with a compilation switch. In other words, writing a tracing aspect is like writing a different chapter, or section, in a book.

So, what makes an Aspect be an Aspect, before we even think of programming it with AspectJ? Given the name we chose for it, which clearly influences our perception, Aspects are software concerns that affect what happens in the Objects but that are more concise, intelligible, and manageable when written as separate chapters of the imaginary book that describes the application. This pseudo-definition of Aspect aligns well with what users have been using AspectJ for. The structural and temporal referencing in AspectJ are essential mechanisms for achieving the separation between the Objects and those other concerns. Those mechanisms are also natural: We would use those kinds of referential relations if we were to write it in English or Portuguese. But the need for better referencing mechanisms doesn't end with what the word "Aspect" conveys.