E-mail Comments from Doug Kimelman


I'm not active in the area, but I've always had an interest in the
notion of "layering" of code, specs, and docs (having written tons of
these over the years, having always kept the various concerns clearly
separated in my own mind as I initially produced the various layers,
and having always been disappointed and frustrated by the resulting
tangle / loss of structure / loss of separation when all of the layers
ended up simply mashed into one another to produce a single text
acceptable to conventional programming systems).

This always suggested to me a 2-1/2 dimensional (at least) structure,
with the 2-D being the plane in which the hierarchical functional
decomposition of the system is embedded, and the 1/2-D being the layers
above that, each layer dealing with a separate concern:
foundation - basic function, second-most-fundamental - error checking,
then parallelization / distribution, subsequent functional extensions, ...
It also seemed that there could well be a graph of dependences among the
layers as well (giving rise to two orthogonal hierarchies: functional
decomposition, and layering).

The only advance I have encountered to date along these lines in a
commercially available environment has been the notion of "applications"
in the VisualAge Smalltalk / ENVY environment -- basically: class hierarchy
layers. These layers being intended primarily for grouping the classes
related to a particular application, clearly separating them from those
of all of the other applications that one might want to load into an image.
A set of selected layers are all superimposed to produce a single hierarchy
in the running Smalltalk image. Existing classes, however, may only be
"extended" by a layer e.g. new methods may be added. No support is provided
for precedence or merging when a number of layers provide the same method
for a given class -- there is no notion of "composition" of methods.

Another perspective from which I am interested in aspect-oriented
programming is that of "distributed application partitioning". Recently, I
have been working on tools for partitioning distributed object applications
across client-server or n-tier topologies. The tool observes an actual run
of the application, records all interaction between objects, and then makes
recommendations to the programmer concerning: how the application should be
partitioned into groups of objects, and to which host machine each group of
objects should be assigned for best overall performance of the application
and for good system load balancing. The programmer then reviews those
recommendations, possibly refines the partitioning, and perhaps even refines
the design of the application to improve performance even further.
Ultimately, the application is deployed on the full topology and executed
in production runs. It seems that a "distribution layer" (or aspect) would
be an ideal arena for this interaction between tool and programmer. The
partitioning tool could make its recommendations in the form of
automatically created program annotations in the distribution aspect;
the programmer could review, alter, and refine these annotations; and
the distribution tool could perform proxy generation and final deployment
driven by these annotations.


- Doug Kimelman



--------------467B82355A909A7F4FBD53F3--