@inproceedings{XAspects:SLS-oopsla-03,
AUTHOR = "Macneil Shonle and Karl Lieberherr and Ankit Shah",
TITLE = "XAspects: An Extensible System for Domain Specific Aspect Languages",
booktitle = "OOPSLA '2003, Domain-Driven Development Track",
YEAR = 2003,
MONTH = "October"
}
How is XAspects related to modules? Experience with XAspects (plug-ins: class dictionary, traversal, visitor, COOL, RIDL) indicates that the aspect languages are carefully designed so that an aspect has only limited control to influence the system. For example, a visitor aspect can only modify a traversal that has been introduced by a traversal strategy.
My view is that domain-specific aspect languages are safer and easier to use than a general-purpose aspect language like AspectJ. They provide for better separation of concerns than a general purpose language. However, AspectJ-like languages, like Socrates, provide an excellent infra structure. to implement the domain-specific aspect languages.
Aspectual Collaborations, while being fairly general purpose, would make a good plug-in for an XAspect system. They can express more aspects than a typical XAspects plug-in yet they have better software engineering properties. In a first implementation of AC in XAspects, all join points should be exported without restriction. AC have desirable properties even in the presence of an "export all join points approach": type-safe separate compilation, structured join points through the aspectual methods.