Hi Gregor:

Crista and I assumed that the aspect description languages are already designed
(Cool and Ridl). You are right that we need to be careful that the
aspect descriptions don't talk to much about the details in the classes.

The reason why we have this discussion is that we use a different
approach to weaving than Crista does and I would like to know
the pros and cons.

We think that it makes sense to have a generic weaver for Java and a set
of join points for Java. Any aspect which addresses only those join points
can be woven by the genric weaver after a translation step for the aspect.

The generic weaver takes as input a Java file and a set of files,
one per aspect, containing editing instructions with respect to the 
join points.

We are not sure yet how well this works when several aspects address 
the same join point. But we think we can resolve this by giving 
ordering instructions to the weaver, if needed.

In our approach we want to factor out the aspect independent weaving
job as much as possible to have a system where we can easily add more
aspects by translating into the intermediate language of the weaver.

Crista has a different concern: She wants to sell her class code
in byte-code form and still be able to vary the aspect descriptions.
We do that too with the traversal aspect: we can sell the byte code
for our classes and still modify the traversals by reading them from
a file at run-time, for example.

So the difference between Crista's and our approach is that she
repeats the basic weaving for each aspect while we factor out
the basic weaving task. I like the NU approach better at this point
but I would like to find out more.

-- Karl
PS. I will be traveling for a week starting tomorrow.

>From gregor@parc.xerox.com Tue Aug 12 12:56:10 1997
>Sender: Gregor Kiczales <gregor@parc.xerox.com>
>From: Gregor Kiczales <Gregor@parc.xerox.com>
>To: lopes@parc.xerox.com
>CC: dem@ccs.neu.edu, AOPCore+.PARC@xerox.com
>Subject: Re: engineering the aspects
>
>
>   Date: Tue, 5 Aug 1997 12:42:17 PDT
>   From: Cristina Lopes <lopes@parc.xerox.com>
>
>   Karl asked me to send out this mail, as a summary of a conversation we
>   had over the telephone. This is about how to _implement_ aspects, and
>   the possibilities you have in engineering the output code.
>
>   (Terminology: "aspect" is the issue for which you provide the means of
>   separate description (...); "aspect program" (or "aspect module") is
>   the separate description itself.)
>
>I'll resist the temptation to say something about this, to focus on the
>rest of this message.
>
>   The engineering decision which is the focus of this note is whether
>   you process a class and its associated aspect programs together or in
>   separate. For certain aspects you may not have a choice. However, for
>   the aspects in D (and also for the Demeter traversals?) you do have
>   this choice.
>
>I'm not sure what you mean by "engineering decision" here, but let me
>point out that I don't think this is an "implementation decision",
>i.e. a decision about *how* to implement the aspect language.  This is
>at least as much a "language design decision which has important
>implementation ramifications".  After all, you could design an aspect
>language so that the weaver has to have knowledge about much, if not
>all, of the component program in order to work.  Or you could design an
>aspect language so that the weaver could never require something like
>that.
>
>Once you've committed yourself in the aspect language, there is some
>serious engineering work to be done about *how* to implement a weaver
>that has that much knowledge.  Do you want to delay weaving until load
>time?  Or do part of it at compile time?  Etc?  
>
>So what's going on here is the standard interplay in language design
>between what is implementable and what you want to document in the
>language.  The language designer must strike a balance between designing
>things: (i) that are useful, (ii) that are implementable, and (iii) for
>which there is sufficient implementation leeway to allow the
>implementations to evolve in the ways they will need to over time.
>
>   Both approaches have advantages and disadvantages. Processing a class
>   and its aspect programs together is good, since you have all the
>   information you need to generate exactly the right code, and, more
>   importantly, no more than that code. However, it has the disadvantage
>   that if you change the aspect program, you have to re-weave the class;
>   and if you change the input class you may have to re-generate whatever
>   auxiliary structures you have for implementing the aspect programs.
>
>   The other approach is to process classes and aspect programs in
>   separate. The advantages and disadvantages of this approach are
>   exactly the opposite of the first one. That is, this is bad in that
>   when weaving a class you have no information about the particular
>   aspect programs. Therefore you need to prepare for all possible
>   situations. As consequence, you need to weave much more code than it
>   would be necessary if you knew the aspect programs. However, classes
>   and aspect programs become totally independent at the execution level:
>   any changes on aspect programs imply only the re-generation of the
>   auxiliary structures for implementing aspect programs, not the weaving
>   of the class; any changes on the class imply only the re-weaving of
>   the class, not the re-generation of the auxiliary structures for the
>   aspect programs.
>
>   In my thesis, I follow the second approach. I understand that you guys
>   follow the first. In the beginning, I was also processing everything
>   together, and I still think it's a valid approach. However what made
>   me lean towards the separate processing was that this second approach
>   opens the possibility for shipping executable class code (not source
>   code) and still being able to modify its behavior wrt the aspects, by
>   pluging it a different aspect program. I think this is neat.
>
>
>   Although I'm not familiar with the "new" Demeter with Traversal
>   Objects, I suspect that it did the same engineering shift, compared to
>   the "old" Demeter. Or maybe not? If you change some class (say, add an
>   instance variable), what exactly do you need to re-generate now?
>
>   -Crista
>
>