Why do we need XAspects

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 gt 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 AspectJs 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/intermedia
  te 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
DJ DemeterJ/DJ/DAJ

• AP concern-shy programming
• DJ 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

7
Component/aspect languages?

• Other relevant, but different, tools for
  domain-specific component
• languages are ExCIS\citesdp-vanderbilt-white-ba
  tory,
• JTS\citebatory98jts, and DiSTiL\citesmaragda
  kisdistil.

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
Simple compilation
Complex weaving
Shyness (white box)
Information hiding (black box)
Y
Y
X
I
X
I
X Y-shy gt X robust wrt Y
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
DJ DemeterJ/DJ/DAJ

• AP concern-translucent programming
• DJ 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

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
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
Simple compilation
Complex weaving
adaptiveness (white box) translucent
Implementation hiding (black box) opaque
Y
Y
X
I
X
I
X Y-translucent gt X robust wrt Y
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) 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
Shyness in Programming

• Karl Lieberherr
• Demeter Research Group
• Northeastern University
• Boston