[aspectj-dev] clearing the residue

["Mik Kersten" <beatmik@xxxxxxxxx>]

I've noticed the phrase "dynamic residue" in recent AspectJ documentation
prototype UI screenshots. It is a great phrase for describing the
implementation of the runtime tests that check if advice will run. However,
I suggest that we stop using it in communication that is visible to users.

A driving goal of the tools and documentation is to help the programmer
reason in terms of the AspectJ language abstractions and not the
implementation details. For example, the extra stack frames that are added
for calling out to advice should be hidden by an AspectJ debugger. Advice
executes implicitly and that's what the tools should show. There may be
useful scenarios for considering the implementation details (e.g. resource
constrained environments where every frame counts, or inlined advice). But
those are secondary.

If we emphasize implementation details we will fall into the old
"preprocessor" trap. It took us a long time to convince users to stop
thinking of AspectJ as having text transformation semantics. Similarly, we
should not encourage users to think of advice as bytecode inserted into
their classes that perform tests to see if the aspect should be called. The
phrase "dynamic residue" encourages people to think of pointcuts in this
misleading way. Also, "residue" has the connotation of something that is
secondary or left over. To the AspectJ programmer advice is just as primary
a part of the language semantics as method calls. 

Gregor has said that for naming AOP concepts, we should ask ourselves
whether they preserve meaning across a range of implementations all the way
from pre-processor to interpreter. If we had the same AspectJ language as
today, but with a pure VM implementation, the concept of "dynamic residue"
could go away. But the runtime test for advice would still exist. 

So I suggest sticking to our previous phrase of "runtime test". That said,
it is important to indicate to the programmer whether a runtime test
controls whether advice will run. So the gutter icon for the corresponding
shadow can have a question mark overlay indicating the test, and even have
an additional link to a the corresponding primitive pointcut(s). The key
thing is that the tools encourage the programmer to reason about the
abstractions, and not our weaving and implementation.

Mik

--
http://kerstens.org/mik