Subject: RE: separation of implementation concerns
From: John Sung (john_j_sung@yahoo.com)
Date: Wed Jan 30 2002 - 14:12:21 EST
Hi Karl,
Here's my analysis of the situation:
As we discussed yesterday, there's couple of step in the main process of
this project.
1. Generate a Class Graph of the code
2. Using the AP library, generate the appropriate traversals
3. "Weave" the traversals into the program
Now, as we discusses, it would be best if we could seperate out these 3
steps and that would be very useful. So, each part will be mostly be
independent of each other and have some kind of interface between them. Most
likely some text format.
In step 1, there are many different ways of getting the class graph, from
the java files, class files, or from the ajc compiler. The java files and
class files have a problem where I would have to write code to parse through
the data to get the information that I want. But the ajc compiler method has
the problem where the ajc compiler could change. I would argue that if we
use AspectJ aspects to modify the ajc compiler then theortically we can
easily modify with the changes in ajc to compensate for it. I'll try to
leave a very good documentation in my thesis so that if anyone else wants to
modify it then they should be able to do this. Oh, and if I do this "right"
then theoretically, my code should be able to take in any parse tree and
spit out a class dictionary. So, from my point of view, using the ajc
compiler makes lots of sense. Otherwise, I would have to create some kind of
parser.
2. For this step, the code should just take in some class dictionary and
some traversal then use the AP library to generate traversal code in AspectJ
aspects. This should be segmented in such a way that anyone can replace the
backend to target the traversal generation process to some other tool.
3. This step would be the trickiest. But for my thesis, this step would be
easy, since the traversal code is in AspectJ, so all one has to do is just
run the AspectJ code on user code and the traversal code.
I don't understand what's gained by having the *.trav files, except that you
don't need to type in "declare traversal". You can make things in aspects as
"public" and it can be referenced from other aspects. So, I really don't see
the need for this new file format.
John
-----Original Message-----
From: Karl Lieberherr [mailto:lieber@ccs.neu.edu]
Sent: Wednesday, January 30, 2002 8:56 AM
To: john_j_sung@yahoo.com
Cc: com3362@ccs.neu.edu; dougo@ccs.neu.edu; johan@ccs.neu.edu
Subject: separation of implementation concerns
Hi John:
here is even a better way to implement your thesis project.
The goal is to have an easy to maintain addition to AspectJ.
We discussed the language integration issues and implementation techniques
yesterday in COM 3362.
Theo suggested that the best way to create the class graph is to get
it from the class files. Please talk to Johan: he is our expert
in residence how to read and modify class files. You
need only the reading part.
It is important to see that this is a very generic task
not specific to AspectJ and some people have probably already done it.
Maybe you can find some code for this on the web.
The second point is to put the traversals into a traversal aspect file
which has the following form:
traversal aspect A {
t = from Company to Salary;
t1 = from Division to Department;
...
}
Such a file will have an extension *.trav and when we invoke your
compiler
ajc-sung *.java *.trav
the following will happen:
1. Desugar the AspectJ aspects in *.java by translating
traversal(t) to call(* t(..)) and
crossing(e) to call(* e_t(..))
2. Read the *.trav files and for "t = from Company ..." produce
a temporary implementation
aspect Traversals {
Company.t() {}
}
in file Traversals.java
3. ajc *.java // using standard AspectJ
This should compile and produce *.class files.
4. Produce the class graph by a separate program
cg-extract *.class > cg
5. Use the cg and the AP library to generate the permanent implementation
aspect Traversal {
Company.t() { ... }
Division_List.t() { ... }
}
in Traversals.java
6. ajc *.java // using standard AspectJ
This will weave it all together.
Ease of maintenance:
1. If AspectJ changes we might have to update step 1. It is unlikely
that AspectJ will change in this part.
2. If the class file format changes, we have to modify step 4.
Unlikely.
None of those steps requires modification of AspectJ code which
shows proper separation of concerns for the implementation
approach and an approach we can maintain independent of how
the AspectJ team rearranges their code.
The advantage of the above separation is also conceptually useful.
All traversal specifications are in one place rather than scattered
through several aspects. This will incourage traversal reuse
and composition with join and merge.
-- Karl
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
This archive was generated by hypermail 2b28 : Wed Jan 30 2002 - 14:35:52 EST