Advice execution as partial order over the control flow

From a theoretical point of view one can interpret the order of advice execution for an Aspect-oriented programming program at a given Join point as a partial order:

First we assume that all pieces of advice are around advice. This is WLOG because any piece of advice can be translated in such a way.

For any given joinpoint p , we have a set advice(p) of pieces of advice that match p . (This set may of course be empty.) This leads to the partial order *forall a in advice(p): a > p.

Usually for such pieces of advice it is undetermined which one is executed first. Some languages as AspectJ always give the first piece of advice that appears in a given compilattion unit the highest priority. But at the latest if those pieces of advice are spread over various aspects, this leads to confusion and indeterminism. Thus actually all Aspect-oriented programming frameworks enable programmers to specify certain precedences of aspects over others. In combination with the first stated, first executed rule, this leads to the following total order: *forall a in advice(p): a > p *forall a_1,a_2 in advice(p): a_1 > a_2 iff **aspect(a_1) has higher prescedence than aspect(a_2) or **aspect(a_1) == aspect(a_2) and a_1 stated before a_2.

Note that this is really only a total order if for all pairs of aspects, prescedences are declared - which is hardly never the case, especially when aspects come from different partys.

Also note that even without AOP it is not always obvious, what method exactly is being called by a given method call. In Object-oriented programming, always the method of the lowest subclass that overrides the given signature is actually called. Thus, the receipient of a call can always be uniquely determined (opposed to AOP), however, it can change during runtime, depending on what runtime type a declared object actually possesses.