In order to make the intended common properties explicit, it would probably be useful to introduce the notion of an advice group signature: (Polymorphic-advice-with-signature)
aspect IncrTracking {
advicegroup trackIncr(FigureElement);
after trackIncr(FigureElement fe):
... // as in polymorphic-advice-with-name
}
This declares explicitly that all advice declarations which belong to the
trackIncr group must have an argument list congruent with
`(FigureElement)'. It is necessary to consider the notion of
congruence carefully, but as a first approximation we could just
assume that the first argument must be the receiver where the given
type must be a subtype of the one in the signature. A congruent
argument list would then have a subtype in the first argument position, and it
would have identical argument types in the remaining argument
positions. There is a lot of room for expansion in this area, and an
obvious extension would be to dispatch on several arguments, possibly
modeled after CLOS, Dylan [29] or some
other language where multiple dispatch is already available.
Another interesting extension would be to use predicate dispatch [11]. Indeed, the Fred AOP language [25], which is based on Chambers' predicate classes [8] and Ernst et al.'s predicate dispatch [11], exhibits a higher degree of polymorphism by unifying the method and advice concepts to a single concept of `branch.' For this paper we just assume that there is some definition of congruence, and that there is some run-time criterion which will allow us to select a single advice from the given group as the most specific one, or to compose an effective advice from one or more of the applicable advice declarations.