Advice in aspect-oriented programming

From Wikipedia, the free encyclopedia

In aspect-oriented programming a piece of advice describes a certain function, method or procedure that is to be applied at a given join point of a program.

The following is taken from a discussion at the mailing list aosd-discuss. Pascal Costanza contributed the following:

The term advice goes back to the term advising as introduced by Warren Teitelman in his PhD thesis in 1966. Here is a quote from Chapter 3 of his thesis:

Advising is the basic innovation in the model, and in the PILOT system. Advising consists of inserting new procedures at any or all of the entry or exit points to a particular procedure (or class of procedures). The procedures inserted are called "advice procedures" or simply "advice".

Since each piece of advice is itself a procedure, it has its own entries and exits. In particular, this means that the execution of advice can cause the procedure that it modifies to be bypassed completely, e.g., by specifying as an exit from the advice one of the exits from the original procedure; or the advice may change essential variables and continue with the computation so that the original procedure is executed, but with modified variables. Finally, the advice may not alter the execution or affect the original procedure at all, e.g., it may merely perform some additional computation such as printing a message or recording history. Since advice can be conditional, the decision as to what is to be done can depend on the results of the computation up to that point.

The principal advantage of advising is that the user need not be concerned about the details of the actual changes in his program, nor the internal representation of advice. He can treat the procedure to be advised _as a unit_, a single block, and make changes to it without concern for the particulars of this block. This may be contrasted with editing in which the programmer must be cognizant of the internal structure of the procedure.

"Advising" found its way into BBN Lisp and later into Xerox PARC's Interlisp.

It also found its way to Flavors, the first object-oriented extension to Lisp developed at MIT. They were subsumed under the notion of method combination. See, for example, AIM-602 at http://www.ai.mit.edu/research/publications/browse/0600browse.shtml ¹

Since method combination and macros are closely related, it's also interesting to note that the first macro system was described in 1963, three years before Warren Teitelman's PhD thesis. See AIM-57 at http://www.ai.mit.edu/research/publications/browse/0000browse.shtml ²

[edit] Notes

Gregor Kiczales comments the above as follows:

1. Advice appeared separately from Flavors in Maclisp and the Lisp Machine. You could advise any function, just like in Interlisp at the time. The before/after ontology appeared separately in Flavors methods.
2. Method combination and macros were only marginally related until much later, in New Flavors and CLOS, when a macro-like mechanism was provided to allow people to define their own rules for combining methods. Prior to that the rules governing combination of before/after methods and so-called whoppers methods (around) was fixed, and the compiler just generated the code for that. There were things called wrappers, which had macro-like behavior, but I forget when they came around. Traipsing through the various versions of MacLisp and Lispm manual to get this part of the history exactly right could interesting. Or it could be that Howard Cannon or David Moon or someone could actually remember it all exactly.

[edit] External links

• Teitelman's PhD thesis (AITR-221)
• InterLisp reference manual