1. 1 Why do we need XAspects Structure-shyness –Can build DSL objects using constructors and use AspectJ to implement meaning of DSL objects. Is inconvenient (sentence is shorter than abstract syntax tree = object) and Lack of static checking in AspectJ –Hinders static checking of DSL objects Improved AspectJ => makes implementation of plugins easier

2. 2 Another weakness of general aspect-oriented programming is the difficulty of using the language correctly. A novice can easily create an infinite loop in AspectJ if an advice happens to apply to itself. More subtle misapplications of advice can also occur that are not so easily observed. If a custom aspect language is created for a specific domain these misapplications can be checked by the plug- in. While a reusable AspectJ aspect might be able to implement some of the functionalities of an XAspects plug-in, it cannot perform some of the compile time checks needed to ensure that the aspect is being used correctly. Lieberherr [11] discusses extensions that could be made to AspectJ’s static property checker to make it more useful.

3. 3 Currently, the envisioned statically executable advice only works on the lexical join point model of AspectJ. But it can also be generalized to a extensible lexical join point model. For example, we may view 'declare‘ syntax also part of the lexical join point model so that one can write his/her own 'statically exeuctable advice' on this lexical tree to do some domain specific compile-time checking, instead of letting each plug-in do the checking. --Pengcheng

4. 4 Goal of AOSD Decompose problem into –Representation languages that support structure-shy representations of objects (Object representation concern for input/output/intermediate objects) Benefit: define objects in a structure-shy way. Need structure- shy language design (not XML). –domain-specific aspect languages that support concern- shy representations of concerns. Aspect languages are representation-languages-shy.

5. 5 Shyness can be defined in many different ways: An implementation of a concern C_1 is C_2-shy if: The C_1 implementation relies only on minimal information of C_2 implementations. The C_1 implementation can adapt to small changes in C_2 implementations. Topological. A small change in a C_2 implementation leads to a smaller change in the C_1 implementation. The C_1 implementation is loosely coupled with C_2 implementations. The C_1 implementation can work with a family C'_2, C''_2, C'''_2, … of C_2 implementations that are “similar”.

6. 6 Shy: a useful term AP = concern-shy programming –D*J: class-graph-shy programming AOP = module-shy programming –AspectJ is call-graph-shy programming –AspectJ is class-graph-shy programming –AspectJ-DAJ is better class-graph-shy programming Obliviousness: program is aspect-shy D*J = DemeterJ/DJ/DAJ

7. 7 Component/aspect languages? Other relevant, but different, tools for domain-specific component languages are ExCIS~\cite{sdp- vanderbilt-white-batory}, JTS~\cite{batory98jts}, and DiSTiL~\cite{smaragdakisdisti l}.

8. 8 Useful distinction? In this paper, we will refer to these non- crosscutting languages as domain- specific component languages. One example of a domain-specific component language is a parser generator tool. Parser is a weaving tool: sentence and grammar are woven into an object.

9. 9 ? Class dictionaries do not encapsulate crosscutting concerns because class dictionaries only generate new classes; they do not modify existing classes. For this reason the class dictionary language is a domain-specific component language.

10. 10 Mitch Suggestion Spectrum –Oblivious Nothing at all –Information-Hiding Stay outside. Well defined interface –Shyness Goes inside; information restriction Program, structure, class graph, call graph, concern, aspect

11. 11 Information hiding (black box) XI Shyness (white box) XI Simple compilationComplex weaving Y Y X robust wrt Y X Y-shy => X robust wrt Y

12. 12 What is I? A type –Modules: specified by a signature –Translucency: a class graph, constrained by a set of traversal strategies and a set of ordering constraints. See paper by Palsberg on class graph inference from adaptive program

13. 13 Translucent: a useful term AP = concern-translucent programming –D*J: class-graph-shy programming AOP = module-translucent programming –AspectJ is call-graph-translucent programming –AspectJ is class-graph-translucent programming –AspectJ-DAJ is better class-graph-translucent programming The base program is opaque wrt the aspect The base program is oblivious wrt the aspect D*J = DemeterJ/DJ/DAJ

14. 14 Defs. Transparent: Capable of transmitting light so that objects or images can be seen as if there were no intervening material. Not shy at all. Translucent: Transmitting light but causing sufficient diffusion to prevent perception of distinct images. Shy. Opaque: Impenetrable by light; neither transparent nor translucent. Information hiding. Black box = completely shy.

15. 15 An oo program is opaque wrt a library implementation The base program is opaque wrt the aspect An oo program is transparent wrt class graph An adaptive program should be translucent wrt class graph A sentence should be translucent wrt grammar structure

16. 16 Implementation hiding (black box) opaque XI adaptiveness (white box) translucent XI Simple compilationComplex weaving Y Y X robust wrt Y X Y-translucent => X robust wrt Y

17. 17 Tranlucency Kinds Concern-translucent –Graph-translucent CallGraph-translucent ClassGraph-translucent –AP-WildCard –AP-Strategy

18. 18 Testing translucent Concern-translucent: concern translucent wrt other concerns –Structure-translucent: concerns translucent wrt graph structure WildCard: aspects translucent through wildcards –AspectJ: *,.., this, target, args, call, execution, … (call graph) Strategy: three level model using strategies –AP-Call: aspects translucent wrt call graph using strategies »AspectJ: cflow

19. 19 Shyness Only works in the presence of a succinctness property: must be able to derive a big structure from a small one in the presence of a context structure. Small structure and context structure crosscut each other.

20. 20 Switch Topics Crosscutting graphs: strategy graphs and class graphs Improving the design of DJ and DAJ using intersection –Need only one class graph

21. 21 Crosscutting graphs declare strategy: everyBook: "intersect(from University to Book, skipDorms)"; declare strategy: skipDorms: "from * bypassing Dorm to *";

22. 22 How implemented intersect(s 1,s 2,s 3, …, s n ) Size(s i )=c c n : too big Instead?

23. 23 How implemented intersect(s 1,s 2,s 3, …, s n ) Size(s i )=c c n : too big Instead? Create traversal graphs tg i (cg,s i ) Interpret all n traversal graphs in parallel during object traversal

24. 24 How general? The thread synchronization aspect language was taken from the COOL programming language: 19 aspect(Coordination) MusicRegistryThreading 20 changes(MusicRegistry) { 21 declare selfex: register; 22 declare mutex: {register, getCD}; 23 } aspect(Sink) MyAspect extends A implements A, B personifies(Z, L), changes(D)

25. 25 Shyness in Programming Karl Lieberherr Demeter Research Group Northeastern University Boston