[abc] AOSD tutorial comments

Below are a few comments on the tutorial presentation that we had today:

Slide 6:
On the diagram it says static weaving and advice weaving. Although you might
have explained it during the talk, but it is not immediately clear what you
mean. I suggest either using more self explaining terms, like ITD weaving or
having small annotations below the diagram explaining what is meant by
static weaving.

Slide 48:
missing brackets

Slide 49:
newType -> ShadowType

Slide 74:
On this and a few following slides you start talking about soot and how it
produces more optimised woven code. I think it is appropriate also to say a
few words not only about how it compares to ajc, but also how it compares to
javac. Especially if it does some unique optimisations.

Since soot itself contains several subprojects, it might be useful to have
one diagram explaining what they are and how they relate to each other.

Slide 83:
Oege mentioned that dava was useful for decompiling woven code and applying
optimisations by hand before trying to actually implement them. Why not to
put it on the slide?

Slide 110:
SomePointcutExyt -> SomePointcutExt

A few more general suggestions:
I think it is absolutely necessary to show an overview diagram of packages
and possibly some major classes in them, before you show any bits of the
project code. And then while you show bits of the code explaining the
changes you need to make for a correct extension, also to show a little
graph that would illustrate in which package of abc the change is actually
happening. I think it will be much more illustrative than lots of code that
was shown and people sort of had to guess from the class and interface
names...

Several questions during the talk were asked in order to clarify how
important the precedence of the extensions in abc is. I think this bit was
not explained at all on the slides, but is quite important. I suggest to
have at least one example, that illustrates what the consequences of the
different orderings are, what potential subtle errors can be.

Sometimes, especially during the open modules part, there was just too much
of code that was not really possible to comprehend while trying to
understand what the speaker is talking about and what open modules actually
intend to do. Exactly during these bits of presentation one could notice
that people were loosing interest and starting checking emails or so... One
solution would be to use simpler examples than let's say open modules. Or
another solution is to explain changes that have to be done at a higher
level of abstraction than code. I think abc needs a good piece of
documentation and there examples like open modules or tracematches would
perfectly suit.

While you have used two different examples of introducing new aspectj
features, namely global and cast, for different parts of the presentation,
it may be worth trying to limit yourself just to, let's say cast, and
explain everything just about cast. While I can go home, download abc and
try implementing global as it is explained during the tutorial, I certainly
cannot do it for cast, although it is a more general and interesting
example. Another reason why that might be better, is because you would only
need to explain one aspectj feature(cast) and then concentrate a substantial
amount of talk explaining more detailed how to define the appropriate
extensions, rather than talking about so many different things that people
can just get lost because of the amount of information so intensively thrown
at them.
We should not overwhelm people with huge amounts of information and make
them feel stupid, and instead rather try to explain less but more
efficiently so they leave the tutorial having clearly understood "the
basics" of defining abc extensions. Sometimes "It's easy as abc" sounded
like an offensive joke.

I liked Ondrej's final part of the talk. I think he has used very nice and
easy to understand graphs to explain the cflow and other analysis.

That's it from me. Hope it helps.
Elnar
Received on Tue Mar 21 21:39:00 2006