RE: [abc] AAA keynote draft

Thanks for the feedback, Heffalump!

It's a pity you won't be there to barrack from the audience at
AAA itself :-)

> >>
> >> Jimple is clearly a good language for implementing such pointcuts, but
> if
> >> you just expose it in its raw form then the power users will make no
> effort
> >> to specify what their pointcut means. I think that's a recipe for
> disaster.
> >
> > I think you have to give programmers the freedom to write any static
> > analysis; you need control over how the runtime properties you're after
> > are statically approximated.
>
> Could they not specify their pointcut as a combination of runtime
> monitoring and a semantics-preserving static analysis that makes it
> efficient? That way Jimple need only be exposed to them for the latter
> purpose.

Perhaps. The static analysis often makes a deliberate approximation that is
a design decision in the aspect; I'm not sure in such cases you want to
specify *both* the analysis and the runtime property it approximates.
[Writing specifications in your code is a good thing, but it should be
optional...]

As a concrete example, consider "update the view after the model changes".
You could program that by tracking exactly what memory locations are read by
the view, and when one of those locations changes, you do a re-draw.
It's clear, it's pure runtime monitoring, but it's woefully inefficient.

Instead, it is up to the programmer to make the decision to statically
approximate when the "model changes". There are many different levels of
precision that could be chosen: all approximate "memory location X may be
read by view and may be written here". No automatic choice of static
analysis can tell you what the right level of precision is.

So I would hope that if we exposed the whole program in Jimple form to
pointcuts, it would be possible to build up a set of good analyses that
programmers use in practice. It would clearly be undesirable if
applications programmers have to think in terms of Jimple when writing
a simple aspect.

The strongest argument for exposing the whole program to pointcuts, however,
is one of simplicity. Any fixed but limited choice of joinpoints (as we
currently have in AspectJ) involves an ad hoc decision; there will always
be applications where that ad hoc decision bites you.

I expect that at AAA, there won't be that much controversy about pointcuts
that range over all instructions; but they probably want it to be the AST,
and not some intermediate representation like Jimple. This crowd has been
shouting for years about "source code analysis and manipulation"...

Cheers,

-Oege
Received on Sun Oct 22 10:36:11 2006