%% WAS:

%Aspect-Oriented (AO) programming languages support typically two
%kinds of mechanisms to incrementally add a concern to an application:
%enhancements to class graphs and enhancements to dynamic
%call graphs. 
%In the vision of this
%paper, adding a concern to an application means 
%(1) expressing the class graph of the concern and implementing it
%in terms of methods and aspectual methods (abstract nodes representing
%nodes in dynamic call graphs) 
%(2) attaching the class graph of the concern
%to the class graph of the application and
%(3) attaching of nodes in the dynamic call graphs to
%aspectual methods. This step
%enhances the dynamic call graphs by adding or modifying computations.

%This paper presents an AO language that follows this vision
%with special emphasis on proper modularization mechanisms.
%The approach to (3) is simple, while the focus of the paper
%is on (1) and (2).

%% IS:

The mechanisms that {\AOP} languages use to incrementally add a concern to an application at first seem contradictory to those that a module system uses to provide manageability and productivity.
We illustrate that this is not the case, and that the combination indeed can be very-straight forward, requiring few exotic features or implementation strategies.

%% END change

A known AOP problem addressed by several authors is the difficultly to
tease out and reuse aspects that are tightly integrated into host
code~\Cite{Ernst:2000:SCTW}.  The reason why aspects are often so
tightly integrated with the host code is the lack of an encapsulating
interface between the aspectual unit and the rest of the system.
This paper addresses this issue by combining the power of aspects with
the encapsulation power of modules.  We demonstrate that writing aspects
against formal participant graphs, and attaching them to other participant
graphs, helps in making the aspects both more abstract and reusable.

We have presented {\ac}s, which combine the static properties of modules:
encapsulation, external composition, and separate compilation, with
the flexible programming power of aspects.  {\ac}s are a wrapper around
Java, which adds a module system and support for aspectual behavior and
separate compilation.  We have shown how the system implements separate
compilation of aspectual and additive behavior; allows composition and
parameterization of collaborations; and can transparently interface
with existing Java programs.  We have elided the description of the
implementation, which is implemented as a somewhat involved desugaring
of aspectual features to a module language back-end.


%\johan{We had issues with the size of the interface vs the size of the behavior.  c.f. Theo's example. So we should point out that all is not well.}

\twelve{
This paper has additionally compared {\ac}s against two popular aspect-oriented
systems, on a small but reasonable example, to evaluate the overhead
of each system, and if possible to gauge whether the presumed overhead
of our system is ``worthwhile''.
}{
Summarizing an external comparison, we find that there is a low overhead to using the encapsulation offered by {\ac}s, when compared to {\aj}'s aspects or {\hj}'s HyperSlices when these are programmed to promote reuse, while offering the considerable benefits of separate compilation and type safety.
}

We expected {\ac}s to, by design, be better than {\aj} at reuse,
but under perform on a small sized example, since the extra syntax of
a module language may be comparatively cumbersome for a small program.
Much to our delight, we found that compared to reusable aspects in {\aj},
{\ac}s are only somewhat more verbose, but at the considerable benefit
of separate compilation and type safety.

We expected {\ac}s to offer modular power similar to {\hj}, but with better aspectual features. 
This was borne out. 
We did find that {\hj} brackets allow before and after advice to be written fairly easily, but simulating around advice was quite tricky, composing hyperslices with differing names was quite verbose, and controlling the details of the generated output was awkward.  
{\hj}'s features work well when working with a set of hyperslices with common and recurring names, allowing its composition functions to be used with the mergeByName matching.
\RevC{Fiddly is an awkward word.}

The {\ac}s advantage shows up when composing very different
collaborations, with differing names and participant graph shapes.
Additionally, {\ac}s will do even better when precise control is needed
over which members are to be visible from a composed collaboration,
and when one collaboration is to be reused several times in different
contexts, with the same advice applied to signatures of different types.
% Not many attempted to compare let alone improve.  We done both.