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 definean initial behavior plus a set of join points in that behavior.

Comparing

• AspectJ

• DemeterJ

• DJ

• ATC

• AspectC

• Aspectual Collaborations

• D (COOL, RIDL)

• BETA

• RG

AspectJ

• from Xerox PARC

AspectJ 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?

AspectJ 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.

AspectJ BJP

• before, after, around: a pointcut.

• can refer to thisJoinPoint– explain join point object:

• instance of JoinPoint class. Interface: getSignature(), getActualParameters(),…

• JoinPoint has eleven subclasses: CallJoinPoint, ReceptionJoinPoint, ExecutionJoinPoint, ExceptionJoinPoint, …

• in around (instead of) can say: proceed()

AspectJ 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 eachJVM() 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)

AspectJ AU

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

DemeterJ

• From Northeastern

DemeterJ JPM

• traversal method calls on Java object, constructor calls

DemeterJ 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

DemeterJ BJP

• visitor classes– before *

DemeterJ CSB

• adaptive methods– void f() to S (V1, V2)

DemeterJ 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 methodsvoid f(ClassGraph 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.

AspectC

• From the University of BC

AspectC JPM

• function calls, variable references

• data available: args to function calls

AspectC 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 !

AspectC BJP

• before, after, around

AspectC CSB

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

AspectC AU

• concatenated to the source

ATC

• From Doug Orleans at Northeastern

ATC JPMAspects 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 AspectJ). 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: <aspect-of-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 AspectJ to implement collaborations/adapters

• AspectJ can only express the adapted collaborations ? It has abstract pointcuts.

• AspectJ supports interfaces with full methods and multiple inheritance

Goal

• Input: classes, collaborations, adapters

• Output: AspectJ code

D

• From Northeastern, continued at Xerox PARC

D

• From Crista’s thesis and implemented in DemeterJ– 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

f1

s1f2

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 AspectJ ?

What is an aspect?

• An aspect turns a tangled and scattered implementation of a concern into a well-modularized implementation of a concern.

• An aspect is a modular unit of cross cutting implementation.