John Lamping's position paper at the ECOOP '97 workshop on AOP
gives further insight into join points and AOP weaving. Examples are from 
Crista's language D.

-- Karl

                  The Interaction of Components and Aspects 
                         John Lamping, Xerox PARC
                          lamping@parc.xerox.com

One of the realities of aspect oriented programming is that aspect code and
component code interacts.  For example, in the D AOP for distributed
computing, the aspect code for communication interacts with the component
code at every message send to a potentially remote object.  The component
code initiates the message send while the aspect code describes how to
marshall the arguments.

If there was no interaction then there would be no need for AOP; you could
just compile the component code and the aspect code separately, using an
appropriate compiler for each language.  It is the interaction between
component and aspect code that makes weavers necessary and that makes AOP
interesting.

And the interaction is typically pervasive: at the level of abstraction at
which the code is written, the component code and aspect code are
addressing different properties, like basic functionality and
communication, that each pervade the computation.  This means that there
the points where the component code and the aspect code interact will also
be pervasive.  These are the join points.

Another part of the power of AOP comes from the ability of the component
code and the aspect code to decompose the join points differently.  For
example, in D AOP, different message sends in the component code, with
different message names, might be treated the same by the code for the
communication aspect if they are all sending the same class of argument.

Crista: I don't understand the last example. Can you elaborate?

Again, if this weren't the case, if the component code and the aspect code
wanted to decompose the computation the same way, there would be no need
for AOP; you could just merge the aspect code into the structure of the
component code.  It is the different decompositions of the join points that
requires weaving of the component and aspect code, not just merging them.

Typically, the component code determines the broad outlines of the
computation, including what join points will exist.  For example, in D AOP,
the component code determines what messages will be sent.  So the component
code not only has a structure under which it views the join points, but
also brings them into being.

The aspect code, on the other hand, typically works with the join points
that the component code provides, although it imposes its own structure on
them.

Different AOP's can be classified in terms of what the join points are and
how the components and aspects interact.  One important class of AOP's is
those where the aspect code treats each join point independently.  The
communication aspect of D AOP falls into this category, with each message
send handled independently.  One result is that the weaver is quite simple,
and structure of the woven code looks basically like the component
structure, with code added at join points.  Composition filters fall into
the same category.

Another category, the join points are not treated independently.  For
example, in order for a loop fusion aspect to fuse two loops, it must
examine both loops from the component code (which may potentially not even
be adjacent in the component code).  Similarly, thinking of monads as
an aspect language, they can relate fuction invocations---their join
points---that are far removed in the component code.