Polymorphism in connection with aspects in AspectJ is generally inherited from the base language, and the aspectual polymorphism features that we have identified and discussed are completely resolved at compile time. By definition, this makes it ad-hoc polymorphism. Moreover, the fledgling support for aspectual polymorphism in AspectJ invites further developments because it has some limitations and irregularities. Based on this analysis, we explore what kinds of genuine, dynamic aspectual polymorphism AOP languages could support.
Aspectual polymorphism can make aspects more expressive and reusable across programs, yet keep them safe. In particular, late binding of advice would be at least as powerful as ordinary late binding of methods, in the sense that a base language without late-bound methods but with late-bound advice would be able to simulate late-bound methods by a simple, general technique. Advice subjected to an environmental polymorphism mechanism would be at least as powerful as the wrapper technology in component systems (e.g., BeanContext, EJB container, JINI container, and stateless web services) in the sense that it would allow separation of nonfunctional requirements and business logic concerns [9], and in that the behavior of the component is parameterized by the runtime environment in which it happens to run.
Inclusion polymorphism is key in OOP and environmental polymorphism is key in component technology. Aspectual and environmental polymorphism would likely play a critical role in many new and unexplored issues like AOP frameworks, componentized aspects, aspectual components, and more.