From Metaprogramming to Aspect-Oriented Programming. Éric Tanter University of Chile DCC/CWR

Transcription

1 From Metaprogramming to Aspect-Oriented Programming Éric Tanter University of Chile DCC/CWR

2 Outline Metaprogramming and Reflection Open Implementations Aspect-Oriented Programming

3 Metaprogramming & Reflection

4 Programs and Data Fundamental distinction appearing in 1830s Charles Babbage s Difference Engine No.2 store with data, mill with programs von Neumann architecture (1958) data and programs are stored in the same memory a program could manipulate another program as data (and even itself!) Theoretical computer science Turing machines: the universal TM (1936) Church lambda calculus: higher-order functions (1984)

5 Concepts [Maes87] data data program program world processor metasystem processor computational system (base) domain reason / act causal connection

6 Reflection Reflective system CS accessing its own metasystem Seminal work of Brian C. Smith [Smith82] 3-LISP A process integral ability to represent, operate on, and otherwise deal with itself in the the same way that it represents, operates on and deals with its primary subject matter. Pattie Maes [Maes87] study of OOP in reflective architectures

7 Reflection and Adaptation Reflection operators [FriedmanWand84] metalevel (evaluator) reification absorption base level (program) introspection: program observes its evaluator state intercession: program modifies its evaluator state

8 Structure and Behavior Structural reification implicit structures accessible as first-class entities eg. classes, methods, fields in Java Reflection API Behavioral reification implicit events of execution accessible as first-class entities eg. MethodCall object with receiver, method, args eg. creation, field access, finalization, etc., as objects

9 Reflection and OOP A Good Match reflection provides power for adaptation OOP provides structure and locality encapsulation message passing object-oriented interfaces proper decomposition incremental specialization of default implementations

10 Metaobject Protocols customized processor processor meta base implicit explicit

11 Example Simple MOP for controlling method calls class TraceMetaobject extends Metaobject { public Object handlecall(methodcall call){ print( before calling + call.getmethodname()); Object result = call.perform(); print( returning with result + result.tostring()); }} Vector v = MOP.create(Vector.class, new TraceMetaobject()); implicit protocol explicit protocol watch out the infinite recursion!

12 Example: Concurrency class Buffer { Object[] elements = new Object[MAX]; int top = 0; public Object get(){ return elements[top--]; } public void put(object o){ elements[top++] = o; } } thread safe? public synchronized Object get() throws InterruptedException { while(top == 0) wait(); Object o = elements[top--]; notifyall(); return o; } public synchronized void put(object o) throws InterruptedException { while(top == MAX) wait(); elements[top++] = o; notifyall(); } hard to write & inefficient

13 A MOP for Concurrency Sequential Object Monitors based on a MOP for controlling method calls [CMT04] call mo t1, put t2, get scheduler buffer schedule: Buffer with: BufferScheduler class BufferScheduler extends Scheduler { Buffer buf =... ; void schedule(){ if(buf.isempty()) scheduleoldest( put ); else if(buf.isfull()) scheduleoldest( get ); else scheduleoldest(); }} explicit protocol implicit protocol simple & efficient

14 Open Implementations

15 Open Implementations Reflection in the context of programming languages reify structure or execution semantics of programs Notion can be generalized implementational reflection led to open implementations

16 Implementational Reflection [Rao91] Reflection can be used to build malleable systems of all kind not only interpreters and compilers! systems also depend on other systems they use computational reflection implementational reflection reflective architecture open implementation

17 Definitions implementational reflection [Rao91] Reflection that involves inspecting and/or manipulating the implementation structures of other systems used by a program open implementation A system with an open implementation provides (at least) two linked interfaces to its clients: 1. a base-level interface to the functionality 2. a metalevel interface that reveals some aspects of how the base-level interface is implemented

18 Duality... Computational <> Implementational a language interpreter is the implementation of language the interface of any system can be seen as an interpreter for that language different characterizations of the same essential ability

19 Structure of an OI base level interface metalevel interface metalevel interface points at which base-level behavior can be customized with different semantics and/or performance causal connection is trivial MOPs = OI of interpreters [Kiczales+91] compile-time MOPs = OI of compilers [Lamping+92/Chiba95]

20 Opening Up Implementations contrary to the black-box abstraction principle!!! any realistic system implies a number of tradeoffs the higher the level is, the more tradeoffs no single fixed implementation will satisfy all users [Kiczales92] I found a large number of programs perform poorly because of the language s tendency to hide what is going on with the misguided intention of not bothering the programmer with details [Wirth74]

21 OI Classical Example A performance issue in class-based languages how are instance variables (slots) implemented? (defclass position () (x y)) many instances, both slots always used (defclass person () (name age address ...)) many instances, only few slots used in one given instance array-like representation hashtable-like representation

22 The CLOS MOP Open implementation of CLOS [Kiczales+91] (allocate-instance class) (get-value class instance slot-name) (set-value class instance slot-name new-value) (defclass hashtable-class (std-class) ()) (defmethod allocate-instance ((c hashtable-class))...allocate a hashtable to store the slots... (defmethod get-value...) (defmethod set-value...) (defclass person() (name age address ...) (:metaclass hashtable-class))

23 OI Philosophy Black-box abstraction: tricks/hacks White-box abstraction (eg. open source) no guarantee that code is well-enough structured Open implementations: reify some aspects of the implementation open up the implementation, but in a principled way [Kiczales92] explicitly focusing on the metalevel as a separate and first-class interface [...] forces a greater attention to exposing important design and implementation choices [Rao91]

24 OI Advantages Support variability in a system s implementation performance tuning semantic customization No need for direct support for rarely-needed features eg. CLOS standard: backward compatibility vs. new design support a CLOS region rather than a CLOS point

25 Open Implementations languages: CLOS [Kiczales+91] compilers [Lamping+92, Chiba95] operating systems: ApertOS [Yokote92] window systems: Silica [Rao91] reflective systems: Reflex [Tanter+01]

26 Providing OIs System [Kiczales+93] System System2... UseCase1 UseCase2... OI design: think of a range of systems which range? iterative process, feedback, refinement

27 OI Interface Styles Declarative style declare expected usage of the module [Kiczales+97a] makeset( n=5, insert=high ) + user friendly, abstract - automatic choice can be hard Strategy style choose strategy in fixed list makeset( LinkedList ) Layered style strategy + possible to provide a new strategy makeset( myset ) + precise selection - might choose badly - limited set of strategies [strategy] + open set of strategies - more complex (for both)

28 Reflection and OIs OI Interface styles as design patterns eg. Strategy for strategy and layered OI styles but explicit representation of any aspect of a system can compromise efficiency badly lazy reification for making implementation state explicit Reflection/MOPs implicit and selective reification of some aspects possibly adaptable at runtime OIs come from generalization of reflection, reflection can be used to implement OIs! [Rao91]

29 Mastering Locality Fundamental though hard to grasp many MOP architectures were locality experiments 5 coarse notions discussed in [Kiczales93+] feature textual object strategy implementation access individual features indicate what behavior to change possibly per-object basis affect individual strategy simple change simple, incrementality

30 Towards AOP Kiczales effort to understand locality led to AOP very often, the concepts that are most natural to use at the meta-level cross-cut those provided at the base level. We are, in essence, trying to find a way to provide two effective views of a system through cross-cutting localities. The structure of complex systems is such that it is natural for people to make this jump from one locality to another, and we have to find a way to support that. [Kiczales92]

31 Aspect-Oriented Programming

32 Crosscutting [Kiczales+97b] Handling crosscutting localities... Generalized-procedure languages only offer one composition mechanism: procedure call (exception handling) Requires calling site to explicitly make the call Some properties cannot be composed this way without breaking modularity

33 AOP GP language (OOP, functional, etc.) weaver application components and aspects application with tangled concerns aspect language(s)

34 Conceptual Model View a program execution as a traces of events occurring at runtime time Match aspects on event patterns Synchronize Logging

35 Aspect Languages Terminology event: join point pattern of events: pointcut code at matched events: advice Aspect languages can be general purpose (GPAL): eg. AspectJ domain specific (DSAL): eg. COOL, SOM, etc. Proper use of AOP means that users are expressing implementation strategies at an appropriately abstract level, through an appropriate aspect language, with appropriate locality. [Kiczales+97b]

36 Example Aspects aspect = modular definition of a crosscutting concern examples trace / log / monitoring GUI refresh (MVC/observer) security checks exception handling concurrency, OS scheduling distributed applications invariant checking, coding style, etc.

37 AspectJ [ First developed at Xerox PARC, now part of Eclipse & IBM Most mature AOP proposal to date AJDT for Eclipse support Model aspects as new constructs (extended Java) dynamic join points, pointcuts and advices inter-type declarations

38 AspectJ by example Autosave No instantiations in loop Caching Observer pattern

39 Autosave aspect Autosave { private int unsavedactions = 0; after() : call(* Application.save()) call(* Application.autosave()) { unsavedactions = 0; } aspect state pointcut advice kind } } after(): call(* Command.execute()) { unsavedactions++; if(unsavedactions == 5) Application.autosave(); advice body

40 No Allocations in Loop class AppThread extends Thread { void run() { while(true) {... } } } aspect NoNewInLoop { }} pointcut noalloc(): execution(* AppThread.run(..)); before(): call(* *.new(..)) && cflow(noalloc()) { System.err.println( Allocation ( + count + ) at named pct control flow + thisjoinpoint.getsourcelocation()); reified current jp

41 Caching aspect FibCaching { private HashMap cache; pointcut fibs(): execution(* Fib.calc(..)); before(): fibs() &&!cflowbelow(fibs()) { if(cache == null) cache = new HashMap(); } int around(int n): fibs() && args(n) { if(cache.containskey(n)) return cache.get(n); else { int result = proceed(); cache.put(n, result); return result; }} } non-recursive replace exec expose arg execute original

42 Caching ctd. abstract aspect Caching { private HashMap cache; abstract pointcut cached(); abstract definition before(): cached() &&!cflowbelow(cached()) {...} } } Object around(object o): cached() && args(o) { if(cache.containskey(o)) return cache.get(o); else { Object result = proceed();... } aspect FibCaching extends Caching { pointcut cached(): execution (* Fib.calc(..)); } concrete extension

43 Observer Pattern aspect Observer { private Vector Subject.observers = new Vector(); inter-type declaration } after(subject s) returning (Observer o): call(observer.new(..)){ s.observers.add(o); o.updateview(); } after(subject s): call(* Subject.update(..)) && target(s) { for(observer o : s.observers){ o.updateview(); } } expose return value expose target

44 Wormhole example: trace fib including the top-level value aspect TraceFib { pointcut fibcall(int n) : call(* Fib.calc(..)) && args(n); pointcut topcall(int n): fibcall(n) &&!cflowbelow(fibcall(int)); pointcut wormhole(int n0, int n): cflow(topcall(n0)) && fibcall(n); before(int n0, int n): wormhole(int n0, int n) { } System.out.println( Calling fib( + n + ) + for fib( + n0 + ) ;

45 Wormhole Pattern Deep in call graph, need some context information present further up normal solution: add a (useless) context parameter to all intermediate methods AOP solution: capture info in a pointcut, and introduce it in advice when needed Pattern caller space: where context info is available callee space: where context info is needed

46 Wormhole Pattern aspect WormholeAspect { pointcut callerspace(<caller context>) : <caller pointcut> ; pointcut calleespace(<callee context>) : <callee pointcut> ; pointcut wormhole(<caller context>, <callee context>): cflow(callerspace(<caller context>)) && calleespace(<callee context>) ; before(<caller context>, <callee context>): wormhole(<caller context>, <callee context>) {... }

47 Disclaimer AOP is not only for objects although it is most used in OOP today AOP is not metaprogramming/reflection although it comes from it, and can be implemented with it AOP is not AspectJ although it is the most mature Java implementation (IBM) AOP is not (only) an academic curiosity although it brings a number of unresolved challenges

48 Current Research Issues Implementation (optimization, dynamicity, etc.) More expressive aspect languages stateful aspects, trace matches, logic predicates, etc. Aspect interactions what happens when aspects affect the same event? what is the visibility of structural changes (ITDs)? Domain-specific aspect languages combining multiple approaches? ease of defining extensions/new languages?

49 Conclusions

50 Reflection & Metaprog. Powerful conceptual framework Modularize concerns at the metalevel Highly generic Excelent for system software (languages, middleware, etc.) But complex Meta viewpoint Hard to control locality Costly

51 AOP A paradigm that precisely aims at proper modularization of crosscutting concerns proper syntactic support from aspect languages Very promising high attraction in both research and industry Lots of open issues tool support standardization development process (mining, analysis, design, testing)