From lorenz@ccs.neu.edu  Mon Jul 30 20:47:15 2001
X-UIDL: 7bc7f3e48ad9fee5e1d123c79e85351b
Return-Path: <lorenz@ccs.neu.edu>
Received: from markab.ccs.neu.edu (lorenz@markab.ccs.neu.edu [129.10.117.126])
	by amber.ccs.neu.edu (8.10.0.Beta10/8.10.0.Beta10) with ESMTP id f6V0lDX18836;
	Mon, 30 Jul 2001 20:47:13 -0400 (EDT)
Received: (from lorenz@localhost)
	by markab.ccs.neu.edu (8.10.0.Beta10/8.10.0.Beta10) id f6V0lDI25726;
	Mon, 30 Jul 2001 20:47:13 -0400 (EDT)
Date: Mon, 30 Jul 2001 20:47:13 -0400 (EDT)
From: "David H. Lorenz" <lorenz@ccs.neu.edu>
Message-Id: <200107310047.f6V0lDI25726@markab.ccs.neu.edu>
To: johan@ccs.neu.edu, lieber@ccs.neu.edu
Subject: FW: OOPSLA 2001Technical Paper notification
Cc: lorenz@ccs.neu.edu
Status: RO
Content-Length: 4354


*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=

First reviewer's review:

          >>> Comments <<<

This approach to collaboration of aspects seem really interresting.
However, I am somewhat concerned with the complexity of the proposal.

Will it really be possible for programmars to master this system - along
with classes, etc., etc. Perhaps they are ...

And I am also concerned about the scalability of the proposal - does it
really work in large-scale systems?



          >>> Points in favour or against <<<

+ well-written

- complex system (usefull?) - scalability ?





 =*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=

Second reviewer's review:

          >>> Summary of the paper <<<

This paper explores an improved approach that combines aspect and
object-oriented programming for composing code fragments to build a system.



          >>> Comments <<<

I like this paper. It is interesting work.  There are only a few
suggestions that I have for improvement. In the introduction, state what
your contributions are. I got confused in the discussion of deployment in
Figure 2. In particular, do you mean by the "two colored rectangles" the
two-toned rectangle, or the two parallelograms? Deployment has one
two-toned rectangle, one round-edged rectangle and 4 parallelograms. In
section 2.2, how is an aspectual method of a participant be mapped to
DataToAccess::readOp? Do their signatures need to match? Is it only the
name that can be different. Is the provided invoke method a closure? Can it
be implemented with reflection? Java does not provide a mechanism for
ex.invoke() where ex is a method! In definition 2.2, there is no explicit
mention of aspectual methods.  In the description of Figure 4 in Section
2.3, the discussion would be easier to follow if it were mapped back to the
entities in Figure 4. In the first sentence of Section 5, remove "of" from
the phrase "of that".



          >>> Points in favour or against <<<

Points in favor: Improves previous work in the area.

Points against: A small delta over previous work. Narrow audience.



 =*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=

Third reviewer's review:

          >>> Summary of the paper <<<

Describes an approach to capture aspect-specific code, including necessary
modification code, in separate modules, called aspectual collaborations
(ACs), that are defined over a local and limited world view, called a
participant graph (a class graph with is-a and has-a edges). An AC is a
class with missing features, called expected features. Adapters are used to
combine ACs, connecting provided features from one AC to expected features
of another. Programs are ACs with no remaining missing features.



          >>> Comments <<<

The introduction section is a bit opaque and section 2.1 outright
unreadable.

Say somewhere that your approach is one of 'static metaprogramming' or
'program transformation' -- programmer foresight at the time of adapter
implementation is required to adapt/modify all classes/members required;
your approach does not support, for example, the intercession of all calls
to methods that cross some dynamic security boundary. Therefore, your
approach is quite close to template or macro based approaches - you should
discuss how your approach differs from one based on structured/type-checked
macros.

Your implementation section is too sketchy -- present a bit more detail on
what exactly you do with .class files.

It remains unclear how your adapted classes (the results of applying
adapters) would fit into a bigger picture. For example, if the same class
is adapted twice, how can both be deployed withour causing problems with
existing clients that use dynamic loading/reflection to access the single
class they have been designed for?

Many minor typos and word choice problems; thorough proofreading required.



          >>> Points in favour or against <<<

+ quite interesting

+ some nice ideas

 - embedding into bigger picture not clear

- not very well written; difficult to get an overview and any sense of
having completely understood the points made

- no validation of the presented ideas in the form of case studies or
similar



 =*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=