\RevA{ I think your language principles are very interesting but they are not emphasized. The appendix stays rather remote, although I found it necessary for understanding the paper. The motivations used in writing this paper are based on [Ovlinger et al 2001]. As I understood from the text, [Ovlinger et al 2001] compares HyperJ and AspectJ and outlines their deficiencies. Since this paper is not available to me, it is difficult to grasp the motivations used in the submitted paper and in designing the AC language. (After I was ready with writing my remarks, I noticed that the comparative analysis of AspectJ, HyperJ and AC were given in the appendix. The appendix is very important to motivate the paper but however it is not integrated with the text well). } An {\ac} is a module that captures both Object-Oriented and Aspect-Oriented features. Each {\ac} defines a formal class graph (a collaboration), which can be superimposed~\cite{katz:1993:SCCDS} on another class graph. The class graph consists of Java class-like \emph{participants}, with method and field (members, collectively) declarations. Additionally, a participant can have ``holes'' in its declarations: \emph{expected} members whose signatures are known, but whose implementation is deferred.~\footnote{% Programmers familiar with Java will see the resemblance to \keywrd{abstract} members. At this stage, the main differences is that \keywrd{expected} members do not statically inhibit instantiation, and are not provided via inheritance and overriding.} Lastly, participants can contain a special sort of method: \emph{aspectual methods}, which are able to intercept method executions while allowing the intercepted to remain oblivious to the interaction. Aspectual methods are normally completely oblivious to the signature of methods they intercept (thus remaining generically reusable), but can alternatively choose to (partially) constrain the signature of methods it can work with, buying expressiveness at the price of genericity. Expected and aspectual members offer two alternative ways, explicit and implicit, respectively, to transfer control and information from one collaboration to another. \revA{ I think the underlying principles of AC is very interesting and promising. Especially, I like your graph-based formalization of the Aspect problem. } {\longAC}s are either declared atomically or composed from superimposed constituent {\ACs}. We refer to the act of superimposing as \emph{attaching} a collaboration to a host collaboration; the host collaboration is said to have been \emph{decorated}. Composite collaborations declare an output participant graph, and map participants from constituent collaborations against output participants. This mapping translates types from the constituent kind to the types mentioned in the output graph.~\footnote{% References to external types (such as the Java class library or third party libraries) do not need be translated.} Thus, a composite collaboration is \emph{indistinguishable} from an atomic collaboration programmed to implement the same interface. The interface of the composite collaboration is declared by exporting (or choosing not to) members from the constituents. Expected members are provided with implementations by mapping them to members on the same output participant, or exporting them to be provided later. Likewise, aspectual methods can intercept executions of methods on the same output participant. \ssect{Design Principles} {\ACs} have a very simple design, based on the principles of encapsulation and composition, but are still able to capture the properties we identified in \Ref{Section}{properties}: \johan{please feel free to make these points shorter. This should be an executive summary.} \begin{enumerate} \item {\bf Encapsulation.} A collaboration's interface controls both how external collaborations can access its members and what requirements the collaboration makes when being composed. \item {\bf Hierarchical Composition.} The composition of collaborations generates collaborations that are indistinguishable from atomic collaborations. Thus, the implementor can decide at each stage whether required functionality is best implemented by an atomic collaboration or by composing several existing ones. The composition of a constituent collaboration into a resulting collaboration is called an \emph{attachment}. \item {\bf External Assembly.} Composition is performed externally to constituent collaborations. This allows collaborations to be used simultaneously in various parts of the application, and also to allow the precise implementation chosen to be varied. For example, a simple file-based persistence collaboration can be switched for a more advanced collaboration that talks to a third-party data-base if performance becomes an issue. \item {\bf Non Type-Invasive Extension.} Constituent types are translated to output types during composition: this results in no constituent types remaining in a composed collaboration. Thus, there is no possibility of confusing two uses of a collaboration, as neither use results in references to the collaboration's original types. By writing collaboration behavior over place-holder participant types, this feature can be leveraged to provide class-parametric polymorphism along the lines of \Cite{AFM,BrachaEtAl:1998:GJ}. \item {\bf Non Behavior-Invasive Extension.} Collaborations can be extended in two ways. The composite collaboration contains the combined behavior of each of its constituents (even if it may not export all contained behavior), which can be viewed as extending the constituent's behavior. Additionally, aspectual methods can intercept certain method executions in a constituent collaboration, allowing the collaboration to be transparently extended with additional behavior. \item {\bf Method Interception.} In addition to transparent extension, aspectual methods can modify how another method is executed, allowing arguments to be inspected and exchanged, even controlling if a method execution continues at all. Encapsulation controls which methods can be modified in this manner: only methods that are exported by a constituent collaboration can be intercepted. Thus, the collaboration controls which methods can be modified and which cannot. \item {\bf Generic Advice.} By allowing the programmer to choose how signature-specific an aspectual method is, reusability can be traded off for expressive power. The signatures in aspectual methods are affected by type translation like all other types in a collaboration. An aspectual method can require an argument of type \type{Foo}, which is a participant of the collaboration. By mapping \type{Foo} to a type determined by the signature of the intercepted method, the aspectual method can safely talk about the captured argument (including declaring variables with that type and storing the value in containers) without constraining it to any particular type. Non type-invasive extension thus allows generic advice to access arguments of captured method executions yet remain type safe. \end{enumerate} \johan{talk about:shared state. simple features interacting} \ssect{Limitation} As a research prototype and existence proof, {\ACs} have the disadvantage that they are not as expressive as {\aj} for some problems. For example, in {\ACs} are less elegant than {\aj} at expressing complex join point predicates, such as the Object Form of the Law of Demeter (LoD) \cite{wu:SEA-02}. How {\ACs} should be extended to elegantly capture such complex join point predicates is an open question. \Ssect{Getting Concrete: an Example}{concrete} The distinction between atomic and composite {\ACs} is purely conceptual: all collaborations have a (possibly empty) set of locally declared behavior, and compose a (possibly empty) set of external collaborations. Typically, a collaboration will be either atomic with only locally declared behavior, or composite with only imported behavior, but in general any combination is possible. The common syntax is: \begin{quote} {\small \begin{tabbing} \keywrd{collaboration} \textit{name} \\ $\{$ \keywrd{extends} \textit{collaboration} $\}^*$ \\ $\{$ \keywrd{participant} \textit{formal\_class\_def} $\}^*$ \\ $\{$ \= $[$ \keywrd{match} \textit{role\_constraint}$^*$ $]$ \keywrd{attach} \textit{attachment\_spec} $\}^*$ \end{tabbing} } \end{quote} \RevA{ 4) First explain the important key concepts of the AC language before explaining the language constructs in detail. For example, graph transformation principle, attachment logic, etc. } An {\ac} has an intrinsic name, and declares a set of participants: participants are declared explicitly, or extended (with copy semantics) from external collaborations. These participants are called \emph{output participants}, to distinguish them from the \emph{constituent} participants of attached collaborations. The set of such participants is closed, in that no participants can be added to the collaboration at a later date.~\footnote{% Participants can be added to the collaboration by modifying the declaration---assuming access to the declaration---or by declaring a new collaboration that extends the collaboration in question. In contrast, a Java package can be extended with new classes without recompiling any existing classes.} A collaboration's behavior consists entirely of the members on its participants. An output participant's members are either explicitly declared along with the participant, or added by attaching an external collaboration and mapping one of the constituent participants to the output participant. External collaborations are attached using one or more \emph{attach clauses}. Each clause can attach several collaborations to the output collaboration, mapping the constituent participants to the output participants. The operational effect of such a mapping is to insert all the members from the constituent participants into the corresponding output participant. Additionally, all occurrences of the constituent types in the inserted members will be replaced by the corresponding output participant. %%% %%% JO Nov 15: This paper does not use it, So why do we mention it? I recommend we remove it from %%% grammar and this paragraph %%% DL: What is "it"? %%% Attach clauses can either be written out manually, or generated from a template clause and a \emph{match clause}. The match clause is evaluated against the output participant graph to generate a set of name bindings that generate attach clauses from the template clause. A simple {\ac}, consisting only of locally declared participants, has the same shape as a Java package, substituting \keywrd{collaboration} for \keywrd{package} and \keywrd{participant} for \keywrd{class}. In fact, Java packages have \emph{is-a} relations to collaborations, and a package can be used wherever a collaboration is expected (consequently, classes have \emph{is-a} relations to participants). Thus, the host package \collab{base} (\Ref{Listing}{container}) is a legal collaboration, corresponding to \Ref{Fig}{cachebase} of \Ref{Section}{challenge}. Conversely, a collaboration containing no unprovided expected members can be used like any Java package. %% ******************************************************************************************* %% ******************************************************************************************* %% ******************************************************************************************* %% ******************************************************************************************* \begin{lstlisting}[label=Listing:addGetSet,caption={Defining generic setters and getters},frame=tb,float=tb]{} collaboration addGetSet participant HasAttribute { /* \label{line:hasAttrDef} */ expected String aString; /* \label{line:aNameExp} */ public String get() {{ /* \label{line:hasAttrGet} */ return aString; }} public void set(String aString) {{ /* \label{line:hasAttrSet} */ this.aString = aString; }} } \end{lstlisting} A slightly less trivial collaboration---in that it uses participants and has an expected member---is the \collab{addGetSet} collaboration shown in \Listing{addGetSet}, which given a field on a participant will add a getter and setter method for that field. It declares one participant, \type{HasAttribute}, on \Line{addGetSet}{hasAttrDef}, two methods, \java{get} and \java{set}, on \LinesAnd{addGetSet}{hasAttrGet}{hasAttrSet}.\footnote{The double braces around method bodies are an implementation trick, allowing us to avoid parsing method bodies. See \Ref{Section}{langnotes} for an overview of the implementation.} The expected field, on \Line{addGetSet}{aNameExp} declares that the collaboration \emph{requires} a reference to a field. This example promotes simplicity over genericity, hard-wiring the type of the field to be \type{String}. %% ******************************************************************************************* %% ******************************************************************************************* %% ******************************************************************************************* %% ******************************************************************************************* \begin{lstlisting}[label=Listing:baseGetSetName,caption={Attaching setters and getters for \java{name}},frame=tb,float=tb]{} collaboration baseGetSetName; /*\label{line:collabname}*/ extends base; /*\label{line:extendsbase}*/ attach addGetSet { /*\label{line:attachgetset}*/ Container += HasAttribute { /*\label{line:maphasattr}*/ provide aString with name; /*\label{line:provaname}*/ export set as set_name; /*\label{line:exportset}*/ export get as get_name; /*\label{line:exportget}*/ } } \end{lstlisting} To use \collab{addGetSet}, we need to compose it with another collaboration, mapping the participant \type{HasAttribute} against a participant (or class---remember that classes can be used in place of participants) with the field in need of get and set methods, and also \emph{provide} that field to \java{aString}. \Listing{baseGetSetName} does exactly this against the \collab{base} package of \Listing{container}. By extending \collab{base} (\Line{baseGetSetName}{extendsbase}) the output collaboration \collab{baseGetSetName} (as per \Line{baseGetSetName}{collabname}) will contain all the participants from \collab{base}: \type{Item}, \type{Simple}, \type{Container}, and \type{Main}.\footnote{For pragmatic reasons, all participants declared via extension have all members exported by default, which is the opposite of the case for attached collaborations, whose members are unexported by default.} To the output participants we attach \collab{addGetSet} (\Line{baseGetSetName}{attachgetset}), and map \type{Hasattribute} to \type{Container}. Mapping is performed with the \keywrd{+=} mapping operator, which is chosen to resemble the accumulate operator in Java or C, as it accumulates all the constituent participants into an output participant. In addition to the decoration, \keywrd{+=} also redirects any references of the inserted type, \type{HasAttribute}, to the destination type, \type{Container}.% \footnote{ % By redirecting references from \type{AttributeType} to \type{String}, we achieve type parameterization as a degenerate case of attachment~\cite{AFM,abadi,wegner:wegner-87}. % } Line \LineB{baseGetSetName}{provaname} provides the concrete field \java{name} to the expected field \java{aString}, while the provided get and set methods are exported under more suitable names on \LinesAnd{baseGetSetName}{exportset}{exportget}. The result is that \collab{baseGetSetName} is just like \collab{base}, but extended with a getter and setter for \java{capacity}. \johan{hrm. I liked attribute type, the more I think about it. Bring it back?} \revA{ 5) When you give examples, explain what an example is all about and then explain the code listings. This should align with the conceptual framework introduced in (4). } %% ******************************************************************************************* %% ******************************************************************************************* %% ******************************************************************************************* %% ******************************************************************************************* The challenge problem will be used to motivate other features of {\longAC}s.