Re: [aspectj-users] AspectJ and JBoss AOP implementation

[Nicholas Lesiecki <ndlesiecki@xxxxxxxxx>]

To take an interesting (and well known/documented) example of non
orthogonality from AspectJ itself, after and around advice cannot be applied
to handler join points. A quick review of the mailing list reveals that this
example of non-orthogonality causes confusion among programmers and a loss
of robustness when broadly-defined pointcuts (tracing?) trip over this
restriction.

I don't mean this as a criticism of AspectJ, because I'm aware of the
problems with detecting the end of handler blocks. But it is a good example
of the drawbacks Gregor cites.

Cheers,
Nick


On 1/28/04 3:25 PM, "Gregor Kiczales" <gregor@xxxxxxxxx> wrote:

> 
>> Elizabeth Echlin Harmer  said:
> 
>> Could you explain what you mean by 'orthogonality
>> of join point models'?
> 
> 
>> Yes, because as I suggested, I believe this is one of
>> the crucial properties of AspectJ, and a criteria for
>> any AOP tool to scale.
> 
> With respect to pointcuts and advice, the model is orthogonal if:
> 
> - you can use any kind of advice on any join point
> - you can write any kind of pointcut in any advice declaration
> - you can compose any two pointcuts
> 
> Now it may be the case that two kind of pointcuts compose, but always
> produce a null result, for example call(...) && execution(...). That's
> OK, they still can be composed in the sense that the result is well
> defined.
> 
> This notion of orthogonality is critical from a practical point of
> view. Without it pointcut and advice code is very brittle.
> 
> Consider what happens if I write a public pointcut in one aspect. say
> pointcut aquireResource(): ..., and then I use that pointcut in several
> other places. You'd like your code to still work if I edit the
> aquireResource pointcut, as long as within the domain sematics, the join
> points it identifies really are points where the resource is aquired.
> You'd hate for it to be the case that the code breaks if I happen to
> use a different pointcut construct somewhere in the new definition of
> aquireResource.
> 
> In that sense orthogonality has a real practical impact -- it makes the
> code robust.
> 
> Orthogonality also makes an AOP tool easier to learn and use. In the
> AspectJ model, where pointcut, join point and advice are three clearly
> different and clearly orthogonal concepts, you can understand the language
> in simpler terms.
> 
> - If Njp, Nptc and Nadv are the number of different kinds of join point,
>   pointcut and advice respectively.
> 
> - Then in an orthogonal model, the complexity of understanding the
>   language is something like Njp + Npc + Nadv.
> 
> - In a non-orthogonal model the complexity of understanding the language
>   is something like Njp*Nptc*Nadv.
> 
> That's because in the orthogonal model I can, for example, reason about the
> different kinds of advice, knowing that they each work similarly with all
> kinds of join points. In a non-orthogonal language I have to remember that
> this particular kind of advice only works with these particular kinds of
> pointcut and those kinds of join point. My mental model is much more complex.
> 
> I've described this just in terms of the pointcut and advice join point
> model. But the same holds for other join point models. For example AspectJ's
> introduction and type pattern facility is join point model. The points are
> effectively declarations, the pointcuts are the type patterns.
> 
> 
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users

-- 
Nicholas Lesiecki
Software Craftsman, specializing in J2EE,
Agile Methods, and aspect-oriented programming

Check out my books:
* Mastering AspectJ: http://tinyurl.com/66vf
* Java Tools for Extreme Programming: http://tinyurl.com/66vt

Check out my articles on AspectJ:
* http://tinyurl.com/66vu and http://tinyurl.com/66vv