I think the paper is missing the front-end .... where we motivate
and set up the problem, introduce our goals, define what good
extensibility would be, and define the 6 (or whatever it is ...)
main steps to defining an extension using our approach ...
Here is what I have in mind, please comment:
1) Introduction and Motivation
- Aspect oriented programming is a new field which is rapidly
developing.
- AspectJ is a widely accepted aspect-oriented language.
- In order to experiment with new aspect-oriented concepts and
associated language constructs, it would
be beneficial to have a compiler for AspectJ that was easy to
extend.
- Many such extensions have been proposed .... talk about a few.
- The AspectJ compiler, ajc, has not been designed with
extensibility in mind because it has many other important
design goals, namely it must closely integrate with
the Eclipse platform and must support fast and incremental
compilation.
- The ApectBench compiler, abc, is a completely new implementation
and has been designed from the beginning with extensibility in mind.
1.1) Design goals, in terms of extensibility:
simplicity: it must be relatively simple develop new
extensions
modularity: extensions should be modular, and should not
require rewriting of existing code
proportionality: small extensions should require a small amount
of work/code
efficiency: it should be possible to provide efficient
implementations of new extensions
composability: ideally, one would like to be able to
compose several extensions
1.2) Our approach (and related back to 1.1).
- build on existing tools for the front-end and back-end that
help us reach our goals of 1.1
Polyglot - already supports simple, modular and
proportional front-end extensions.
Soot - already supports a simple IR, modular analyses,
and support for producing efficient code.
- design an architecture for abc that:
- uses the vanilla versions of polyglot and soot (hence
leading to our aspectinfo approach)
- structures the compiler to that each key phase is
extensible, including the matcher and weaver
- illustrate the extensibility by implementing eaj, which
extends AspectJ with four new features (list them here)
1.3) What are our contributions.
1.4) Structure of the rest of the paper.
2) Background - Soot, Polyglot, Basic abc architecture
3) Building an extension - the basic steps.
4) eaj - An AspectJ extension
5) Implementing eaj using abc. (How-examples of basic steps)
(How did it work? How much code?)
6) Related Work
7) Conclusions and Future Work
+-------------------------------------------------------------+
| Laurie Hendren, Professor, School of Computer Science |
| McGill University |
| 318 McConnell Engineering Building tel: (514) 398-7391 |
| 3480 University Street fax: (514) 398-3883 |
| Montreal, Quebec H3A 2A7 hendren@cs.mcgill.ca |
| CANADA http://www.sable.mcgill.ca/~hendren |
+-------------------------------------------------------------+
On Wed, 22 Sep 2004, Ondrej Lhotak wrote:
> I spewed out some comments about the paper on irc. I kept going for
> quite a while before I realized that I was talking to just myself and
> Julian. I'm sending out a copy so all of you can listen to me talk to
> myself.
>
> 16:22 < hendren> I'm thinking now ...
> 16:27 < olhotak> Hmm... I see that it's not easy to organize this paper.
> 16:36 < olhotak> OK, I'm done reading the paper.
> 16:37 < olhotak> It strikes me as somewhat backwards (maybe reading it from the end would have helped). I see the difficulty as a tension between the example
> extensions themselves, and the extensibility of abc in general.
> 16:38 < olhotak> Explaining the examples first really puts the focus on them, and makes the whole paper feel like the examples are the only contribution.
> 16:38 < olhotak> However, we need to say something about the examples first, because we use them to illustrate how extensions are done, throughout section 4.
> 16:39 < olhotak> But, if we just say something brief about them, then we haven't really done the examples justice.
> 16:41 < olhotak> I mean, it *is* significant that the examples are actually real, useful things.
> 16:42 < olhotak> And it doesn't make sense to just say something brief about them at the beginning, then describe them a second time yet again.
> 16:42 < olhotak> I think a big weakness is that section 4 is written heavily in terms of the examples, rather than in general terms.
> 16:43 < olhotak> If it explained what can be extended, why it should be extended, and how it is extended in general terms (within each subsection), followed by
> a small demonstration of how specifically it's done for the examples, that would help a bit.
> 16:43 < olhotak> I'm not sure if it would help enough, though.
> 16:44 < olhotak> Am I just talking to myself here?
> 16:48 -!- cgoard [cgoard@string.CS.McGill.CA] has joined #abc
> 16:48 < julian_> olhotak : nope, we're listening
> 16:49 < julian_> well... I am
> 16:49 < olhotak> Well, Laurie and Heffie are gone.
> 16:49 < julian_> oh
> 16:49 < olhotak> I think I'll put my musings into an e-mail for everyone.
> 16:50 < olhotak> julian_: I think it's important to show the extensions in detail in the paper, because they're significant and it's important to show that
> they're significant.
> 16:51 < olhotak> But on the other hand, we need to convince people that it's more general than *just* those extensions.
> 16:51 < olhotak> I'm not quite sure how to do both at the same time.
> 16:51 < olhotak> Hopefully the others will have an idea.
> 16:51 < julian_> I know what you mean. There is a lot of implementation detail. Wood hiding the trees kinda stuff
>
> Ondrej
>
>
Received on Wed Sep 22 23:53:54 2004
This archive was generated by hypermail 2.1.8 : Thu Sep 23 2004 - 11:40:02 BST