2.8. CLOSING REMARKSUnderstanding something involves both understanding how it works (mechanism) and what it's good for (methodology). In computer science, we're rarely shy about grandiose methodological claims (see, for example, the literature of AI or the Internet). But mechanism is importantappreciating mechanisms leads to improved mechanisms, recognition of commonalities and isomorphisms, and plain old clarity about what's actually happening. The understanding gained through the examination of mechanism leads to generalization and richer systems. The quantification and obliviousness argument is about looking for the common mechanism in AOP systems, seeing how to understand particular AOP systems with respect to those mechanisms, and looking for the places where those mechanisms can be generalized. We're trying to answer the question, "Is X an AOP system?" where the answer is not based on whether the creator of the system called it AOP, but rather on whether its mechanisms can be used to do AOP. Imagine, if you will, Anne, a computer scientist working in isolation, who has invented a language exactly like AspectJ, except that she believes the purpose of the language is to insert debugging statements into conventional Java code. She's called the language "DebugJ," and everywhere AspectJ uses the word "aspect," she uses "debug." Her methodological explanations are all about temporarily inserting only debugging statements into code under development. Is DebugJ an AOP language? Consider Betty, who believes she has invented a new aspect-oriented language called "AspectTran." AspectTran looks just like Fortran, except that "subroutine" has been replaced by the word "aspect." Betty explains that users should encode concerns separately in these aspect routines, and if a concern crosscuts another, they should invoke the aspect code with a CALL statement. Shared state between the aspect and the base routine is passed in parameters to the aspect call. Since Fortran is call-by-reference, one can even have an aspect change the value of a local variable! Betty is proud of how little she had to modify the Fortran compiler to create AspectTran. Is AspectTran an AOP language? If this seems far-fetched, keep in mind how long it took to convince Ada aficionados that Ada83 was not an object-oriented language. Dahl, Myhrhaug, and Nygaard never mentioned that Simula 67 was an object-oriented language. Nevertheless, it's universally acclaimed as the first. Decide for yourself if Ada95 is an object-oriented language: One can do all the object-oriented things by using particular features in specific and non-obvious ways, but the term "object" is not part of the language's lexicon. We have identified AOP with the ability to assert quantified statements over programs without explicit reference to these statements. This implies
|