Dean Wampler's Blog

I started a discussion yesterday on the "aspectj-users" group about "humane pointcut languages":http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg05970.html. The notion of "humane interfaces" in programming has been discussed by "Martin Fowler":http://www.martinfowler.com/bliki/HumaneInterface.html and in the context of user interfaces and product design by "Jef Raskin":http://jef.raskincenter.org/humane_interface/summary_of_thi.html. This conversation was a spin-off of another "thread":http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg05960.html where I made a mistake that I occasionally make. An AspectJ user wanted to apply some after advice after constructor calls in a class that has an annotation, _e.g._,

  @MyAnnotation
  public class Foo {
    public Foo(...) {...}
    ...
  }

He needed help writing the pointcut and advice for this case. Without repeating the whole conversation here, at one point I remarked that

  call( @MyAnnotation * *.new(..) )

matches constructors annotated with @MyAnnotation, while

  call( * (@MyAnnotation *).new(..) )

matches constructors in classes where the class has the annotation. In fact, both are invalid expressions because the first * is for the return type and there is no return type for constructors, so the first * shouldn't be there. Hence, the correct statement is that

  call( @MyAnnotation *.new(..) )

matches constructors annotated with @MyAnnotation, while

  call( (@MyAnnotation *).new(..) )

matches constructors in classes where the class has the annotation.
p. This is the sort of mistake I make fairly often and I'm sure beginners really struggle with the pointcut syntax, although it's generally great for experts because it is both succinct and powerful. However, sometimes a more "human-readable", that is "humane", syntax can be a real benefit. In fact, I've been thinking about expressive pointcut languages quite a bit recently, not so much in this context, but more in the context of higher-level AOP abstractions. As I said in the discussion thread, it bothers me that we discuss high-level concerns, say for example security, then turn around and write PCD(Pointcut Definitions)s using very low-level primitives that tend to reference specific classes, methods, _etc._ Of course, I'm not the only person who thinks this way and the recent work on AO interface-based programming is a huge step towards making it possible to express aspects with appropriate levels of abstraction. I would like to comment on this issue more in future blogs, but for now, let's return to the original problem and look at some things we might do to make PCD(Pointcut Definitions)s more humane. The first thing I suggested in the thread is the addition of special keywords that could be substituted for some of the wild-cards: table{border:1px solid black; background:#eee}. |_<. Keyword |_. Maps To:  |_<. Context | | $any_return |{text-align:center}. * | Used for any return type | | $any_arg |{text-align:center}. * | Used for any _one_ method argument | | $any_arglist |{text-align:center}. .. | Used for zero-many method arguments | | $any_type |{text-align:center}. * | Used for any type expression (class, interface, ...) | So, our previous PCD(Pointcut Definition) that matches calls to the constructors could be written

	call( (@MyAnnotation $any_type).new($any_arglist) )

This is a little more readable, especially for new users, while experts will prefer the more terse form for its brevity. As an aside, you could use a similar mechanism to support regular expression matching while minimizing the potential for confusion, as discussed "here":http://aspectprogramming.com/papers/The%20Challenges%20of%20Writing%20Reusable%20Aspects%20in%20AspectJ%20v3.pdf. Something like $re(/(foo|bar)$/) to match names ending in foo or bar, for example. Let's combine our new PCD(Pointcut Definition) with after advice, to see a little more context. We want to "bind" the newly-created Foo instance to a variable foo. Handling newly-created objects is "tricky":http://www.eclipse.org/aspectj/doc/released/faq.html#q:adviseconstructors.

	after() returning(Foo foo): 
	  call( (@MyAnnotation $any_type).new($any_arglist) ) {
		...
	}

Another approach, if we're using the execution join point, is the following:

	after(Foo foo): 
	  execution( (@MyAnnotation $any_type).new($any_arglist) ) && this(foo) {
		...
	}

However, the keywords are a small improvement. Let me suggest that a real "humane" PCD language should read more like English. Consider this rewriting of the same two expressions, using a made-up pointcut DSL(Domain Specific Language):

	after() returning(Foo foo): 
	  call(constructors().takingAnyArgs().inClassesAnnotatedWith(@MyAnnotation)) {
		...
	}

and

	after(Foo foo): 
  execution(constructors().takingAnyArgs().inClassesAnnotatedWith(@MyAnnotation))
	&& bindNewlyConstructedObjectTo(foo) {
	...
}

This syntax is inspired by the syntax of mocking frameworks like "JMock":http://www.jmock.org and equivalents in Ruby. Certainly my toy DSL(Domain Specific Language) could be improved; I made it up on the fly during the discussion thread yesterday. However, because it reads like English, it is very self-documenting, making comprehension easier by AspectJ neophytes and even experienced AspectJ users who are new to the application. I think it's useful to remember that most code is _write once, read many_. We may not like to type a lot, but a literate style pays dividends over time. Note that the syntax of this DSL(Domain Specific Language) and the standard syntax express essentially the same pointcut language "abstraction" for AspectJ. So, I think there is a place for a more "humane" form of the AspectJ pointcut DSL(Domain Specific Language). Similarly, I think that we need DSL(Domain Specific Languages)s appropriate for higher-level AOP abstractions (_e.g._, at the design level) and ideally AOP DSL(Domain Specific Languages)s that are domain-specific for non-trivial domains. *Update 4/28/06:* Jonas Bonér wrote an interesting blog on "Domain Driven Pointcut Design":http://jonasboner.com/2006/04/24/domain-driven-pointcut-design/ where he discusses good principles of pointcut design that minimize dependencies on fragile class details and instead rely on metadata annotations, _etc._ He also makes an excellent argument that the "language" of those annotations should reflect the domain of the annotated class and not mix in other domains, like cross-cutting concerns.