Henrik, Markus, Stephen:

The way I understand AOP is as a direct result of the work by  
Kiczales et al on Meta Object Protocols and Open Implementation.  So  
the fact that there is a close relationship is not really surprising  
at all.

The new thing about AOP was that the researchers figured out what it  
was they were using meta-programming for:  dealing with  
cross-cutting, non local code.

MI, mixins, method combination and even subject oriented programming  
(Ossher et al) etc. are markedly different.  Although they all  
combine code fragments in one way or another, they all yield a  
localized result.  Method combination produces a single method, MI  
produces a single class and so do mixins (although of course the  
mixin can be mixed into different classes), different subjects  
combine single methods.

Meta programming is different.  Instead of playing with the  
components, you start messing with the meanings of the underlying  
means of composition.  Instead of modifying a method, you change what  
*messaging* means (the change can be global or locally restricted).

However, it turns out that meta object programming provides a very  
powerful mechanism but no really good ideas about how and what for it  
should be used.  ("Here's a Gatling gun, go play with it to find out  
how many ways you can shoot yourself in the foot with it" :-)

I think AOP could be that idea, or at least was seen as that by the  
researchers.   Maybe not *the* idea, but at least *one* very  
important one.

Once you have that idea, it turns out that you don't actually need  
runtime meta object programming to implement it all the time, other  
less powerful, less hazardous and more efficient mechanisms can be  
used in many cases.  So one difference is between an idea and the  
implementation of an idea.  What Czarnecki says reminds me of those  
who claim that OOP is no more than procedures with funny calling  
conventions.  While not 100% false, it really doesn't capture the  
idea at all, and OOP can of course be implemented radically  
differently.

So while mixins/method combinations and even plain OO-inheritance  
can be used to implement AOP, they are just that, implementation  
mechanisms that may or may not be appropriate in specific  
circumstances.  They are not equivalent to the idea.

Anyway, my understanding of AOP (if that's what it is) has been  
helped by contrasting it to a plain OO implementation of such a  
cross-cutting concerns and the tangling that would result.

Take the sparse matrix code as an example, which IIRC, had a base  
algorithm, an aspect for data representation and an aspect for  
numerical stability.  With straight procedural code, you have no  
choice but to manually create tangled code, so the algorithm and the  
different aspects are completely lost in the clutter.

OO gives you a way of keeping the different aspects at least  
somewhat separate, by implementing them as different classes (or some  
as mixins, doesn't make much difference) and providing hooks for  
hooking these different classes together.  Now the different aspects  
are separate, but they're still lost beneath all the "hook" code you  
had to write to join it all together.  Furthermore, the code will  
perform badly because each hook incurs a messaging penalty.

These "hooks" are what are the join-points in framework design.  The  
join points give the framework its flexibilty, but you need an  
explicit join-point for each dimension of variability.

The primary AOP contribution, IMNSHO, is allowing join-points to be  
defined outside the code being modified, in a non-local fashion, and  
using efficient compile time techniques to achieve the flexibility  
usually requiring costly dynamic dispatch and even costlier meta  
programming.


I hope all of this has made some sense, it is the first time I have  
presented these thoughts on AOP, which have been gestating ever since  
I came across AOP for my Diploma Thesis.


Information on GenVoca, Predator and the library scaling problem can  
be found at http://www.cs.utexas.edu/users/schwartz/.

As to Join Points, I think that was the term used by the AOP folks.   
This had merged in my mind with Hot-Spots, which are used in  
framework design.  The original reference is "Design Patterns for  
Object-Oriented Software Development", W. Pree, Addison Wesley 1994.  
I got that from the paper "Design Guidelines for Tailorable  
Frameworks" by Serge Demeyer, Theo Dirk Meijler, Oscar Nierstrasz and  
Patrick Steyaert, in Communications of the ACM, Volume 40, Issue  
10(1997) pp. 60-64.  I have a Postscript of the pre-print of that  
paper I could send you.

You might want to look at my Diploma Thesis "Composition and  
Refinement in Object Oriented Design", downloadable from  
http://www.cs.tu-berlin.de/~marcel/.  It contains a brain dump from a  
couple of years ago on this subject and loads of references.

Marcel