Hi all,
I've just finished a go through the paper and checked in some tweaks
to the intro & section 2, plus some typos fixes. I'm going to start
working on related work / conclusion now. Some more or less random
comments on the main sections:
4.1 Polyglot-based frontend. The description of the frontend is too
vague for me to understand it properly. eg paras 2-3 the overall
implementation of semantics checks is described but at this stage we
have no idea what the aspectj-specific checks are.
Some suggestions for 4.1, what do people think about this?
- leave lexing / parsing as it is
- very briefly describe all the semantics checks that need to be
done [ie mention that declare parents introduces constraints on
hierarchy, and ITD checks...]
- Give fig. 4 at that point to show overall structure of frontend
- The discussion of dependencies between passes needs far too much
background to leave in here; suggest either leave out altogether or
replace with one example
- "the semantic checking of AspectJ source files depends on the
static weaving"... Does it really? (I haven't got my list of aspectj
passes with me!) - in that case it's in the backend anyway... If
semantic checks do occur in the backend this should be mentioned here.
- Finally comment on separation from Polyglot (ie current third para).
4.4 make more of a big deal of reweaving; this is the major
contribution of the architecture of abc (I've emphasized it again in
the intro). Make it clear that reweaving allows analyses of AO
constructs without the pain of having to eg construct an
aspect-specific call graph.
5.1 Name matching: again it's difficult to get the point and we lack
the space to extend it. Suggest collapsing last 2 paras into one,
omitting discussion of EvaluatePatternsAThirdTime...
5.3 ITDs: §2 Visibility:
- rephrase last sentence, not 100% clear to me
§5 AspectInfo and Code Generation: "second, the weaver will
correctly use the aspect as the lexical scope..." - this is a rather
tricky point, esp if people are not familiar with AspectJ. Expand or
remove?
5.4 Advice
5.4.1 Matching
§1 Regularised pointcut language: it's a bit hard to get an idea
of the problem from the first two paras. Suggest giving execution(int
foo()) as example first, and then splitting the things to be matched
against (class / method / statement) afterwards. Could save a couple
of lines ... :)
5.4.2 Weaving
The intro to weaving could be expanded a bit to make it clearer
what the goal is before going into details [in particular preparing
join point shadows...]
§2 Inserting advice: is the discussion of where after throwing
advice needs to be placed really relevant or just a minor detail? If
minor, leave out [space reasons]
6 Comparison to ajc
6.1 The point that abc is better separated from its components is
made clearly, no comments on this section
6.2 last para: "when one compares like with like (ajc+soot and
abc)". Isn't ajc and abc -O0 also comparing like with like? Of course,
in that case we are substantially slower... because of the cost of
converting jimple to bytecode or just load times for soot? In any case
I think this should be addressed as reviewers might wonder about this
Fig. 9. How painful would it be to make the bytecodes / Jimple
statements inserted in weaving boldface? This would make it easier to
understand the figure without referring too much to the text.
6.4 Weaving strategy. There is a bit of overlap in the way this is
introduced with 5.4.2 weaving (in particular when we mention
inserting nops). Rename to "Using standard Soot optimisations" and put
more emphasis on this, payoff being that we can do more things than
ajc [rather than convenience in weaving, which is how it is phrased at
the moment]
Related work, conclusion: I'll look at those in a bit, the goal being
to make the contributions more apparent in the conclusion, so it
doesn't look like an experience report...
General point:
- We ought to have a ref to Hilsdale, Hugunin & Sunnyvale (AOSD
2004) as the only other paper that describes compilation of AspectJ
(advice weaving anyway). Should be mentioned in sec 6
Any comments on these points would be welcome! I'll work them in
tomorrow if people are ok with them, but as they are nontrivial
thought it would be better to check.
It's worth keeping in mind that we are half a page over; should be
easy enough to get rid of, we can certainly do a bit of reference
packing etc but we don't want to add too much stuff now
Cheers,
Damien
-- Damien Sereni Oxford University Computing Laboratory Wolfson Building, Parks Road Oxford OX1 3QD UK dsereni@gmail.com / dsereni@comlab.ox.ac.uk http://web.comlab.ox.ac.uk/work/damien.sereniReceived on Sat Dec 18 17:40:07 2004
This archive was generated by hypermail 2.1.8 : Sat Dec 18 2004 - 20:10:02 GMT