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.

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

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

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

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

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

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

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{smaragdakisdistil}.

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

?

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

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

Information hiding(black box)

X I

Shyness(white box)

X I

Simple compilation Complex weaving

Y Y

X robust wrt Y X Y-shy =>X robust wrt Y

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

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

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

An oo program is opaque wrt a library implementationThe base program is opaque wrt the aspect

An oo program is transparent wrt class graphAn adaptive program should be translucent wrt class graphA sentence should be translucent wrt grammar structure

16

Implementation hiding(black box)opaque

X I

adaptiveness(white box)translucent

X I

Simple compilation Complex weaving

Y Y

X robust wrt Y X Y-translucent =>X robust wrt Y

17

Tranlucency Kinds

• Concern-translucent

– Graph-translucent

• CallGraph-translucent

• ClassGraph-translucent

– AP-WildCard

– AP-Strategy

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

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

Switch Topics

• Crosscutting graphs: strategy graphs and class graphs

• Improving the design of DJ and DAJ using intersection– Need only one class graph

21

Crosscutting graphs

declare strategy: everyBook:"intersect(from University to Book,

skipDorms)";declare strategy: skipDorms:"from * bypassing Dorm to *";

22

How implemented

• intersect(s1,s2,s3, … , sn)

• Size(si)=c

• cn : too big

• Instead?

23

How implemented

• intersect(s1,s2,s3, … , sn)

• Size(si)=c

• cn : too big

• Instead?

• Create traversal graphs tgi(cg,si)

• Interpret all n traversal graphs in parallel during object traversal

24

How general?

The thread synchronization aspect language was taken from the COOL programming language:

19 aspect(Coordination) MusicRegistryThreading20 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

Shyness in Programming

Karl Lieberherr

Demeter Research Group

Northeastern University

Boston