Precedence Order

As shown in Figure 8, since multiple actions can be triggered at the same join point and if more than one such actions are of the same type, we need default precedence rules for the actions:

• $before$ actions are woven just before the join point. In case of multiple $before$ actions, the order of the woven advice follows the exact order in which the actions were defined in source code.

• Next, $after$ actions are woven just after the join point. In the case of multiple $after$ actions, the order of the woven advice follows the exact order in which the actions were defined in the source code.

• Last, multiple $around$ actions are woven around the join point in the exact order in which actions are defined in source code. So the outer-most of the $around$ actions will be the one appearing first in the woven code and it will go around the next $around$ action encountered, or the actual join point if there are no more $around$ actions.

In Figure 8a, multiple actions are targeting a single $call$ join point. The weaving points for a join point in the source code are shown in Figure 8b. All the $before$ actions are woven just before the join point in order they are specified. All the $after$ actions are woven just after the join point. The call to foo is replaced by the call to the first $around$ action, which in turn can call the second $around$ action through its $proceed$ function, and so on.

Figure 8: Actions Precedence Order

[Actions List]

[Weaving Order]

An important point to notice here is that the default ordering rules of AspectMatlab are simpler and more restrictive than the precedence rules of AspectJ [1]. However, our action weaving strategy avoids complicated dependency rules, will not lead to any dependency cycles between actions, and is easy to comprehend from a scientific programmer's point of view. Since our actions have names, it would also be simple for us to introduce a declaration to over-ride the default ordering within each of the around, before and after groups.