\subsection{Properties of Modules}\label{Section:modprops}
The capabilities of module systems stem from several intertwined principles. 
\begin{smallenum}[%
\noindent]

\litem{Encapsulation.} Decoupling the interface from the implementation
allows the implementation of a module to vary without affecting its
clients, as long as the interface remains the same.  We say that
the module \emph{encapsulates} its contents behind an interface.
Encapsulation enables modules to be implemented and managed separately
and in parallel.  The requirements for encapsulation often allow a module
to be compiled separately from the rest of the application, allowing
pre-compiled modules to be distributed as COTS (Commercial Off The
Shelf) components.  While separate compilation is attractive, it is not
as important as the ability for the programmer to analyze and comprehend
a module separately from its uses.  The ability to control visibility
of its contents is key to supporting local analysis of the module.
The problem in such analysis is that it is seldom apparent how a module's
contents are referenced (and possibly modified) by external modules.
By controlling what is and isn't exported, the programmer can control
and identify exactly which parts of the module are understood completely
(as they are not exported) and which are understood partially (as they
are exported and may thus be referenced by unknown external modules).

%%% This generalizes the concept of abstract datatypes, which separate
%%% representation from denotation, to code.

\litem{Hierarchical Composition.} Hierarchical composition of modules
allows larger modules to be constructed from smaller modules, instead of
being written from scratch, with absolutely no functional distinction.
This allows modularity to be used to comprehend, as well as to construct,
an application.  It is easier to understand a large \emph{composite}
module consisting of smaller, assembled modules, than a monolithic
\emph{atomic} module of the same functionality, as the former can be
understood by first understanding the constituent parts and then how they
fit together, while the latter needs to be understood in its entirety to
be understood at all.  Composition is  also important for local knowledge:
a composite module can be traced in a top-down manner to  ``zoom in''
on local behaviors: composition describes how that piece interacts with
the rest of the module, while the atomic module offers no such guides.
If local contents are not exported from a composite module, encapsulation
statically assures that they cannot be referenced or modified by code
outside the composite module.  The tradeoff is that the atomic module
will be able to express complex behaviors that cannot be expressed
conveniently in a composite module.

\litem{External Assembly.} External assembly of modules allows
modules to be written not only independently of each other, but
also \emph{ignorantly} of each other.  Because they are assembled
externally, a module does not need to have explicit references to
other modules.  Rather, modules make explicit the requirements they
make of the environment of their use.  Any environment fulfilling these
assumptions should be sufficient for the module.  Thus, external assembly
of modules removes hardwired assumptions about how a module will be used,
allowing it to be reused in other contexts than originally envisioned.
This allows programmer effort to be saved, but perhaps more importantly,
allows comprehension of the module's behavior to be reused as well.
To promote flexibility, the assembly can often perform limited adaptation
of modules, to reconcile differences in names and types.

\litem{Non Type-Invasive Extension.} In order to achieve type safe
reuse, multiple instantiations of a module must be kept separate, as
they may have been assembled with incompatible imports.  A guiding
principle in this regard is \emph{invasiveness}, defined by Ernst
\Cite{Ernst:2000:Invasive} as whether  ``[a module's influence] can
be detected by inspecting the target module.''  A weaker form of this
property is whether it is possible to confuse one instantiation of a
module with another (if instantiations cannot be detected, they cannot
be confused).  The danger of confusing modules can be illustrated in the
context of role or class-based modules.  It is tempting to instantiate
a module containing a role model by declaring classes in the importing
module as implementing the interfaces declared by the roles.  This is
invasive if it is possible to test dynamically whether an object of
one of the implementing classes is a subtype of a role type.  If the
object is a subtype of a role type, an upcast to that type will make it
possible to confuse it with other classes implementing that role type.
Such upcasts are likely, as if imported role types are visible to the
importing module, it is attractive to expose them in method signatures.

%\newcounter{moduleproperties}\setcounter{moduleproperties}{\theenumi}

\end{smallenum}

\Ssect{Properties for Aspects}{aop-props}

{\AOLs} typically
support two kinds of mechanisms to incrementally add a concern to an
application: enhancements to static program text and enhancements to
dynamic call graphs.  
As was the case for module systems, the powers of aspects
arise from a number of fundamental properties. 
\begin{smallenum}[%
\noindent] 

%\setcounter{enumi}{\themoduleproperties}

\litem{Non Behavior-Invasive Extension.} 
External invariants
%%%
%%% \johan{,such as those expressed by caching and backlink behavior,}
%%%
require their code to be executed at certain points in the base behavior.
The base behavior can be implemented with such extension in mind, by using
the observer pattern or variations thereof.  However, in general, such
foresight cannot be assumed: we want the base to remain \emph{oblivious}
to the invariants imposed on it.  This promotes both clarity, by keeping
the concerns separate, and flexibility, by allowing behaviors to be
extended in ways not foreseen at design time.

The ability to enhance the class graph
with additional behavior or relationships
allows the base to remain oblivious to the extension being added.

\litem{Method Interception.}
%%%
%%% \johan{While the observer pattern will allow an external observer to react to events in the subject, the observer cannot affect the subject.}
%%%
To be able to express complex interactions between concerns, one concern
may need not only to be informed about points in the execution of the
other concern, but also to modify these executions.  Such power could
allow the programmer to gracefully recover from errors by retrying
method calls with different arguments, to implement security features
by only allowing method executions to proceed under some circumstances,
and to optimize expensive computations by diverting calls to special
case methods depending on details of the call.

This ability is called \emph{method interception},
as once intercepted, the method is under outside control.
Such interception can be seen as enhancement of an oblivious dynamic call graph. 

\litem{Generic Advice.}
Exactly what enhancement happens at points in the dynamic call graph is called \emph{advice}.
There is a tradeoff between expressiveness and reusability that needs to be weighed carefully. 
Simple advice is likely quite reusable: the recurring example is a logging concern, which is generally applicable to methods of any signature.
More complicated behaviors, such as performance optimizations, will likely be more tightly bound to the details of the method.
Ideally the programmer should be able to choose how to balance reusability against expressive power.
This choice should not come at the cost of giving up runtime type safety.
\end{smallenum}