« AspectJ on the road... | Main | Using Eclipse 2.1, but want to use the latest AspectJ compiler? »

June 19, 2004

"Go From" Statement Considered Harmful

I was thinking this morning about the best way to explain the rationale for the set of join points exposed by AspectJ's join point model. Join points are events that occur during the run-time execution of a program. There are many such events: the static initialization of a class, a call to a method, the execution of the 2011th bytecode instruction, and so on. Why are the first two of these exposed as join points, but the third is not?

AspectJ's join points are described in the programming guide as "principled" points in the runtime execution of a program. Certainly I hope it is clear that the execution of a method is a more signifcant (and stable in the face of program evolution) event than the execution of an arbitrary line of code. As I was thinking about this, I hit upon the following analogy:

Ever since Dijkstra's famous paper "Go To Statement Considered Harmful," programmers have been wary of using the goto statement, to the point that it is now virtually extinct. Jumping to arbitrary points in the program flow using a goto makes it very hard to understand what's going on. As Dijkstra put it, "The go to statement as it stands is just too primitive; it is too much an invitation to make a mess of one's program." In place of the goto Dijkstra recommends more structured alternatives for specifying program control flow - including if-then-else statements, looping constructs, and procedure calls.

Allowing join points for arbitrary events in a program's execution (and providing a corresponding pointcut designator to match them) would be the aspect-oriented equivalent of the goto statement - the "go from" statement perhaps? In the spirit of Dijkstra's paper then, we can argue "Go From Statement Considered Harmful." AspectJ doesn't provide join points for arbitrary points in the program execution because they would be "just too primitive; too much an invitation to make a mess of one's program." Instead AspectJ provides join points for more structured events in the program control flow - method calls and executions, class and object initialization, and so on. The aim of AspectJ is to help you write clearer, simpler, more direct programs, not spaghetti.

Posted by adrian at June 19, 2004 03:03 PM [permalink]

Comments

I am new to aspect oriented programming, so this may be a bit of a novice question: While I am quite excited about the benefits of AOP, it does seem to me that AOP constructs can introduce some non-explicit and non-obvious control flow into the application. Good development tools could be used to combat this to some extent by calling out when advice would be run. Without those tools, understanding control flow would require some good documentation or a deep familiarity with the entire application, it would seem.

What are your thoughts on this? How are people handling this on a day-to-day level?

Posted by: Andrew at July 3, 2004 12:16 AM

Post a comment