Re: [abc] nice paper! :)

[ sorry if you're getting this twice, I don't think it went through the first time i sent it as i used the wrong address, so i'm resending it ]

Hi all,

I've read the paper yesterday evening for typos and again this morning for more general comments

I really don't have very much to say, overall I think the paper's very good as it is (and I think Ondrej's preempted many of the comments I had :). I'll make the changes on subversion for the typos; here's a fe general comments:

(btw these might refer to either the version on cvs last night or this morning at 8ish)

  ***** Structure

Section I, Design Goals: the analysability goal is really quite different to the other three, as they refer to the design of the compiler, whereas this refers to its functionality. Maybe adding an extra sentence in between the first three and it along the lines of "in addition, we require..." would make it more obvious

Section II. This is a very nice introduction of the main building blocks. At the end of 2.2 though I'd expand a little on the transformation jimple -> bytecode, to stress that it produces efficient bytecode, using as few locals as possible

Section III.
   3.1. I agree with Ondrej that the discussion of the lexer is far too long, it's really not necessary to go into that much detail as the only thing that should be stressed is the extensibility (mentionning briefly that this is an improvement over Polyglot). The statefulness should be mentionned, but just as a couple of sentences.
      I actually also think that the parser description should be extended a bit, although Figure 2 makes it quite clear, just to emphasize a bit more the fact that you can extend the grammar without touching it

   3.2. The description of the extensibility of the type system is getting a bit confused with the description of name class pattern expressions here. It's a good example, but I would argue that we give a bit too much detail on the specific example (in particular "it is not advisable...", end of par 2 is a bit cryptic as it stands)

   3.4. Last paragraph: clearer just to say that AST nodes help the aspect separation process in two ways: generating new placeholder methods, and generating specific stuff in AspectInfo. The first is only applicable to constructs like advice or if(...) pointcuts that introduce java code

   3.7 Advice: the first paragraph is overly vague, and my initial reaction on reading it is that i don't believe it (new types of advice is a very general notion, and claiming that it is all easy to do is not very convincing). The problem is that there are very few extra possibilities following the aspectj advice model (except Ondrej's Before-After advice, which we implement anyway to do cflow) so that new types of advice would probably be a radical departure from that model. Start with the second paragraph, and say that new types of advice can be created if necessary, and give the eg of BeforeAfter very briefly

Section IV.

   4.1 The exposition of the private pointcut is a bit hard to follow. Its goal should be obvious, ie information hiding (although that might be an alien concept to the AspectJ people). The point is that you can bind a variable, test it with an if(), but hide it from the pointcut. The stuff about args(int) distracts us from the main focus

Section V.

I like this section pretty much as it is. The only thing that i can think of is that some of the code is possibly not necessary, or even confusing. I understand that it's important to show as much code as possible, but eg. the GlobalPointcutDecl factory method (5.3) and the overridden listShadowTypes() (5.5) are really boilerplate code that could just be described, rather than written out.

Section VI and 5.8

Figure 5 has moved to just below Figure 4 and it is too easy to compare them and see the discrepancy before it is explained. Possibly a footnote should be added, from the caption of Figure 5

Section VII

What about composition of extensions? This is a point that I didn't pick up while reading the paper (I may have missed it!) and I actually can't remember whether we support it or not. Either way it should be mentionned as either a feature or future work/discussion

  ***** Minor comments

A few minor things that I've picked up but that aren't really typos:

   How do we want keywords (and in particular, names of new pointcuts) to appear in the text? It is not very consistent as it stands, although all the AspectJ pointcuts seem to be in bold, so maybe we should go through & make sure all the new pointcuts are also in bold

   "Static Weaving". Figure 1 and section 2.3 (last par). It is clear from context what this refers to, but I think an alternative name should be preferred anyway. Static weaving appears to be mostly opposed to run-time weaving (a google on "static weaving" confirms that - the first few pages all use it that way) and I remember horrible discussions at AOSD '03 because people were all meaning different things by static/dynamic advice etc... If possible it would be nice to have a name that nobody will find confusing

Right, that's all, folks :)

Onto fixing typos / adding javadoc to my code / preparing a talk for tomorrow / writing my own paper / arguing with my bank
aargh

Cheers,
Damien

------
Damien Sereni
Magdalen College
Oxford OX14AU
damien.sereni@magd.ox.ac.uk
(0870 120 0870) 25764
Received on Wed Sep 29 11:33:31 2004