AspectOriented Programming is Quantification and Obliviousness

1
Aspect-Oriented Programming is Quantification and
Obliviousness

• Presented 070410
• Advanced Programming Language 888

Josh King The Ohio State University
2
The report

• Robert Filman and Daniel Friedman
• NASA technical report
• Workshop on Advanced Separation of Concerns,
  OOPSLA 2000
• What prompted their paper
• Is event based publish and subscribe (EBPS) AOP?
• (prompted by question from Tzilla Elrad)
• Message of the report The two properties
  quantification and obliviousness are necessary
  for AOP

3
Caveat lector
Arent saying AOP is the end-all be-all Theyre
saying the way AOP should be.
4
Earlier models

• First programming languages
• A statement is
• unitary (exactly once)
• local

procedures
locality broken
inheritance
5
Quantification

• Need quantification when there are statements
  that have effect on many loci in the underlying
  code
• Quantification the specification of where these
  loci are

6
Tiny example

• Traffic movement simulation program
• Want to add display aspect
• Quantification whenever something moves, the
  screen must be updated
• Where to put the display call
• Could use send-super approach
• Need a cooperative programmer for child classes
• What if a programmer forgets to abide by the
  contract
• Programmers are not always cooperative
• Cooperation is not good enough

7
Obliviousness

• System should not rely on programmers compliance
  with a contract to be correct
• mixin inheritance
• code of derived class is assembled with code of
  the advising super class
• derived class is unaware of super class and
  whatever concerns the super class takes care of
• This means dont need a contract with the
  programmer.

8
AOP, in general
This breaks with local and unitary demands
9
Quantification Types

• Static structure
• Black Box (simple to implement wrapping)
• advise by interface
• Clear Box (harder to implement compiler)
• good for debugging
• Dynamic behavior
• advice quantified by runtime status of program
• exceptions
• calling a certain procedure from a certain other
  method
• patterns on the history of program execution
• their example after the try password routine
  fails five times
• abstractions of quantification depend on
  underlying language

can you wrap an access to a public variable?
10
Other dimensions

• Context
• how much of P should A be able to reference
• Quantification scope
• upon what elements in P can be conditioned
• Dynamic quantification
• dynamically changing the set of actions /
  conditions
• Incomplete obliviousness
• e.g. Application needs to set tasks priority
• Action interaction
• two actions needing to talk to each other
• Relative aspect orderings
• two actions applying to the same location
• Inconsistent aspects
• two actions that violate each others semantics
  need a way to detect and prevent
• Weaving
• how to weave? compile time / run time

11
Possible AO languages

• Tzillas question Whats an aspect-oriented
  language
• Rule based systems
• e.g., Prolog purely dynamically quantified
  statements
• the idea that other things going on besides the
  main flow isnt the least bit strange
• but hard to program
• sequential nature destroyed
• classical AOP augment conventional sequential
  statements with quantifications
• Event based, publish and subscribe
• Quantification is apparent
• Is EBPS oblivious?
• depends on applications programming style
• events as interface between components vs.
  introducing a contract that programmers publish
  events
• Intentional Programming and Meta Programming
• direct execution order in arbitrarily defined
  computational patterns
• environments for writing compilers, rather than a
  realization of the AOP idea
• Generative Programming
• transforming higher-level representations of
  programs into lower-level ones
• creator of a GP system may internally aspects
  deemed important

12
Their closing remarks

• AOP is not about OOP
• AO can be done w/o OO
• pleasant environment vs. necessary one
• AOP is not useful for singletons
• if your orthogonal concern is only going to be
  used in one location, no need for an aspect
• toy examples for academic exploration excluded
• Better AOP systems are more oblivious
• what if the programmers usual mode of
  programming is to do so with an eye on
  crosscutting concerns

13
BACKUP SLIDES
14
Question from Tzilla Elrad

• This work was prompted by a question from Tzilla
  Elrad, who asked whether event-based, publish and
  subscribe (EBPS) (for example, 9) is AOP.
• EBPS event producers publish to an event
  channel consumers register with event channel
  for event types of interest
• The paper looks at
• the event types that various languages are
  capable of describing
• various algorithms which can be used to quickly
  process incoming events and send them to consumers

15
Language expressiveness and algorithms

• Languages
• propositional
• deals only with event properties
• predicate language
• can form a boolean expression on values in events
  / environment
• temporal language
• expands possible descriptions to include timing
  information

• Algorithms
• (incomplete slide)