Tim is promising to keep us awake by going over the first 3 years of his PhD. He starts by refreshing our memory and explaining that AOP is useful when working with crosscutting concerns, like logging.
The problem with AoP is that point cuts are implicit, only the aspect knows it’s there, places where it will be called are unaware this will happen. This especially leads to problems when code evolves, since you might make changes while not being aware to the aspect. Aspects are like ghosts, they can see you, but you can’t see them.
Tim is going to focus on data analysis, since this is where the errors most commonly occur. An example, we could have an advice that closes a stream, but someone unaware of this, might still try to read from it. Tim is building an advice-impact analysis, based on classic definition-use analysis. This analysis is designed to run in the background of an IDE and this means that the analysis has to be incremental. The performance of the tool has been evaluated by trying it on random (but realistic) changes to source code.
Design by contract
In OOP, we have the Liskov substitution principle and Tim has been trying to adjust this principle to AOP and this turned out to be quite easy. Whenever a point cut matches, the corresponding advice effectively substitutes the original join point. Hence, the contracts of an advice have to comply with those of the point cut. However, this is not meant for strict enforcement, it just defines the border between safe and unsafe aspects.
Where they meet
With the data flow analysis, we can detect where interactions meet. So then, given an interaction, will the new value result in a contract violation? If the original code implements its contracts, does this still hold with an altered value. These questions are still future work (Tim has two more years to go :)) Aim is to look into tools like spec#, that can statically detect whether a piece of source code complies with a contract.