Hi Crista, Doug and Johan:

we need to help Josh and Kedar with some high-level design decisions
on how to best structure the aspect weaver for Cool.

We would like to have a design which allows to easily add more aspects
with support for some form of incremental compilation.

The idea below is to compile each aspect into an intermediate form
so that aspect weaving is just a "fill-in" operation which 
is faster then full aspect weaving. If one aspect changes without changing
the other aspects, we only need to recompile that aspect and fill in again.
Reweaving becomes faster.

Some ideas are below. Do you think this will work?
Any better ideas?

-- Karl
=========================

We have now the input objects defined in files:

program.cd
program.beh
program.comm

The output objects are Java programs.

The next question is: How do you weave the three files together.
What intermediate objects do you need to do the weaving efficiently?

If only program.comm changes and program.beh and program.cd are invariant,
we don't want to reweave everything from scratch.

A strategy might be to translate program.beh to program2.beh
and program.cd to program2.cd so that

program2.cd
program2.beh

have the same behavior as

program.cd
program.beh
program.comm

There is a better alternative:
The general situation will be:

program.cd
program.beh
program.aspect1
program.aspect2
...

We translate program.cd + program.beh into a file called
Classes.JoinPoints
which contains the Java classes and named place holders for all the
join points.

Then we translate program.aspect1 to a file aspect1.FillJoinPoints and
		  program.aspect2 to        aspect2.FillJoinPoints

The last step is a simple "fill-in" program which reads through
Classes.JoinPoints
and looks up in aspect1.FillJoinPoints and aspect2.FillJoinPoints
what needs to be filled in.

The advantage of this approach is that it is incremental:
If aspect aspect1 changes, we update aspect1.FillJoinPoints
and "fill-in". We don't have to recompile everything.

The question is whether this approach is general enough to work
for most aspects. Many details need to be worked out, such as:
How is the code combined if multiple aspects refer to the same
join point.

How does a file aspect1.FillJoinPoints look like: maybe 
some editing instructions like:

prefix method A.f JavaCode
suffix method A.f JavaCode
around method A.f JavaCode (boolean condition)
add class X JavaCode
add method f() to class X
add instance variable f to class X