Features of AOP languages AOP languages have the

Features of AOP languages • AOP languages have the following main elements: – a join point model (JPM) wrt base PL – a specification language for expressing sets of join points (JPS) – a means of specifying behavior involving join points (BJP) – encapsulated units combining JPS and BJP (CSB) – method of attachment of units to base program (AU)

Features of AOP languages • AOP languages have the following main elements: – a join point model (JPM) wrt base PL – a specification language for expressing sets of join points (JPS) – a means of specifying behavior involving join points (BJP) – encapsulated units combining JPS and BJP (CSB) – method of attachment of units to base program (AU) JPS and BJP are sometimes overlapping. JPS might already define an initial behavior plus a set of join points in that behavior.

Comparing • • • Aspect. J Demeter. J DJ ATC Aspectual Collaborations D (COOL, RIDL) BETA RG

Aspect. J • from Xerox PARC

Aspect. J JPM • principled points of execution – message sends (basically a method call), message receptions, method executions – field references (get and set) – exception throwing and handling – constructor execution • which context is available at each join point?

Aspect. J JPS • pointcut designators – primitive: calls(sig), receptions(sig), executions(sig), instanceof(type), within(type), cflow(pcd), getter(sig? ), setter(sig? ) – operators: &&, ||, ! • can name a pointcut and expose context – pointcut foo (V v): pcd (using v); • pointcut maybe abstract (declaration) and defined in a subaspect.

Aspect. J BJP • before, after, around: a pointcut. • can refer to this. Join. Point – explain join point object: • instance of Join. Point class. Interface: get. Signature(), get. Actual. Parameters(), … • Join. Point has eleven subclasses: Call. Join. Point, Reception. Join. Point, Execution. Join. Point, Exception. Join. Point, … • in around (instead of) can say: proceed()

Aspect. J CSB • an aspect contains a list of advice and point cut declarations and introductions and regular fields and methods.

Explaining aspect instance • when you declare an aspect, you say either of each. JVM() or of eachobject(pcd) • logging: log stream put in aspect instance of each VM (one instance for whole program) • dft: mark field put it in aspect instance of each object (node object of the graph)

Aspect. J AU • ajc takes a list of files: aspects and classes and weaves them together.

Demeter. J • From Northeastern

Demeter. J JPM • traversal method calls on Java object, constructor calls

Demeter. J JPS • strategies – define family of traversal programs to be enhanced – approximation: function mapping object graphs to subgraphs – are enhanced by visitors • sentences – define family of Java objects: executions of constructor calls – are not further enhanced

Demeter. J BJP • visitor classes – before *

Demeter. J CSB • adaptive methods – void f() to S (V 1, V 2)

Demeter. J AU • make new. beh file, add to. prj file, demeterj

DJ • Java library from Northeastern • Present two views of DJ as an AOP system • Two views – object graphs as join points – object graph slices as join points

DJ JPM • object graph : nodes and edges • principled points: traversal of nodes or edges • fix a traversal algorithm

DJ JPS • strategies – define family of traversal programs to be enhanced – approximation: function mapping object graphs to subgraphs (object graph slices)

DJ BJP • visitor classes – before(A a), after(C c), cbefore_x(Object a, Object b), caround_x(Object a, Object b, Subtraverser st) – each method applies to a different part of the point cut (strategy)

DJ CSB • aspectual methods void f(Class. Graph cg) { cg. traverse(this, “from A to S”, new Visitor() {…}); }

DJ AU • add methods to classes

DJ: Second view: Doug • Doug Orleans

DJ JPM • object graph slices: nodes and edges • fix a traversal algorithm

DJ JPS • strategies – define family of traversal programs to be enhanced – approximation: function mapping object graphs to subgraphs (object graph slices) • in addition: visitor methods are pointcut designators • pointcut designators are encoded in signatures of visitor methods

DJ BJP • visitor classes – each visitor method is advice on the point cut specified by the method signature

DJ CSB • a visitor class is a package of advice • when you use a visitor in a traversal of an ogs (in traverse) then each pointcut is intersected with the traversal pointcut, namely cflow(traverse). (can also use within)

DJ AU • to attach an aspect you call traverse with an aspect (visitor). • traverse expression attaches the aspect to an object graph slice.

Aspect. C • From the University of BC

Aspect. C JPM • function calls, variable references • data available: args to function calls

Aspect. C JPS • point cut designators – call (foo( c )): all calls of function foo with one argument – cflow( any point cut designator): “whatever comes afterwards on the stack” – varref(name) – combine with && , || and !

Aspect. C BJP • before, after, around

Aspect. C CSB • are hardwired together: when advice is given, you need to give point cut

Aspect. C AU • concatenated to the source

ATC • From Doug Orleans at Northeastern

ATC JPM Aspects in Tiny CLOS • generic function receptions, method executions • use MOP to implement aspects • what data is exported: see join point object

ATC JPS ! • point cut designators – predicate on aspect instance and join point object – explain join point object: • instance of <join-point> class. Interface: slots: generic (generic function being called), args (actual parameters), stack (stack of join points in current control flow) • <join-point> has two subclasses: <reception-join-point> and <execution-join-point> • <execution-join-point> has additional slot: method (being executed) • (all the traversal methods in the cflow of the first traversal call)

ATC BJP • before, after, around: take aspect instance and join point object as argument. • around has third arg: continuation • generic function. . .

ATC CSB • advice has a pointcut generic function (like an abstract pointcut in Aspect. J). Methods of generic function are specified separately. • an aspect contains a list of advice (no point cut declaration) • an aspect is an instance of <aspect>

Explaining aspect instance • class <aspect> has two subclasses: <aspectof-each-vm> <aspect-of-each-object > • logging: log stream put in aspect instance of each VM (one instance for whole program) • dft: mark field put it in aspect instance of each object (node object of the graph)

ATC AU ! • <aspectizable> mixin: has slot aspects: holds list of attached aspects • <aspectizable-generic> is a subclass of both <generic> and <aspectizable> (<generic> is the class of all generic functions) • add-aspect! , remove-aspect! • all generic functions in base program are aspectizable (non-obliviousness ok)

Aspectual Collabs • From NU

• join point model allows for parameterization; join point patterns and their instances.

Aspectual Collaborations JPM • principled points of execution ? – abstract join points that are mapped by the adapter to concrete ones – execution of methods modified by collaboration • enhance the class graph: open classes: add more members to existing classes • which context is available at each join point?

Aspectual Collaborations JPM • syntactic methods and fields, not points of execution • Replacement allows us to capture execution • Two kinds of method capture – tradeoff between access to arguments/result vs. generality

Aspectual Collaborations JPS • sets of join points: collaboration + adapter (in the adapters we express the cross cutting) • collaboration roles only: have the flavor of an abstract pointcut. • adapter specifies links between methods and fields • requirements can be exported unfulfilled. • future version: globbing with guard operators

Aspectual Collaborations BJP • before, after, around: for methods • can refer to actual parameters • in replace (around (instead of)) can say: expected() • Depending on which join point model: can access/modify arguments or cannot.

Aspectual Collaborations CSB • collaborations and adapters • Each adapter is processed to generate a new collaboration. Collaborations can encapsulate some behavior and export other.

AC instances • Complicated sharing model • ?

Aspectual Collaborations AU • ac-compiler (non existent) takes a list of files: classes and collaborations and adapters and weaves them together. • Weaving is incremental. Compilation is external to weaving. • Process is finished when no more requirements remain.

Using Aspect. J to implement collaborations/adapters • Aspect. J can only express the adapted collaborations ? It has abstract pointcuts. • Aspect. J supports interfaces with full methods and multiple inheritance

Goal • Input: classes, collaborations, adapters • Output: Aspect. J code

D • From Northeastern, continued at Xerox PARC

D • From Crista’s thesis and implemented in Demeter. J – COOL – RIDL • concern specific aspect language

COOL JPM • principled points of execution – method calls • which context is available at each join point? Can look at objects, but not modify them.

COOL JPS • sets of join points: exclusion sets • exclusion sets do more than defining a set of join points: initial behavior of coodination • enhanced by method managers

COOL BJP • method managers

COOL CSB • coordinators

COOL AU • demeterj: takes coordinators (in. cool files) and. cd. beh and. ridl files and weaves them together.

RIDL JPM • principled points of execution – method calls and object graphs of parameters and return types • which context is available at each join point? Parameters and return values are processed according to transfer specs.

RIDL JPS • sets of join points: for parameters and return types: transfer specifications in portals specify them. Only initial behavior is of interest: selecting an object graph slice. Portals list the methods

RIDL BJP • transfer specifications modify behavior of methods. transfer specs are themselves aspects. Two layers. Similar to AP.

RIDL CSB • portals

RIDL AU • demeterj: takes portals (in. ridl files) and. cd. beh and. cool files and weaves them together.

BETA • from the Beta community (Aarhus, etc. ) • The BETA fragment system: syntax directed program modularization (1983 paper)

BETA JPM • join points – slots: designated positions in the source code – class Leg { <<SLOT leg: attributes>> …} -can weave new declarations into the join point • which context is available at each join point? refer to what is in scope of slot.

BETA JPS • pointcut designators – have to explicitly write a set of slots into the base code or the fragments • one slot name = one pointcut

BETA BJP? • This code goes into this slot.

BETA CSB • Fragment binding process: binding of fragments to slots – fragment groups (named collection of fragments contributing to the implementation of an aspect) – fragment group attributes (origin, include, body): references from one group to another • origin: required (except for basic fragment group); origin chain reached by traversal.

Fragment Graph f 1 s 1 f 2

BETA CSB • a fragment group contains a list of slots embedded in code

BETA AU • Through fragment system organization. Use of include: include dingbats and Color. • static

BETA • need to define the slots where code can be inserted. No predefined join points. • Good at composition of fragments. Fragments may have their own slots. • Base program is not oblivious about aspects. But could have predefined join points.

BETA • A fragment group is a modular unit of cross cutting implementation. It is an aspect.

RG • memoization aspect • compiler related aspects, operate on join points (message sends in the static call graph) – fusion aspect – memory management aspect • modify behavior of compiler: fancy pragma • transformation: almost not AOP • could not be done in Aspect. J ?

What is an aspect? • An aspect turns a tangled and scattered implementation of a concern into a wellmodularized implementation of a concern. • An aspect is a modular unit of cross cutting implementation.