Re: [abc] composition, precedence and hiding

Sounds interesting!

it's superficially similar to Mitch Wand's semantics, though in that a
stack of aspects is applied to a computation, not a statement

I'm a bit unclear on how an AspectJ-like language would be translated
into this formalism - presumably you still need some form of
composition of aspects with classes? I guess this could be evaluated
by pushing down the aspect composition to the level of statements with
the with { .... } construct?

It might be interesting to compare this with other formalisms for
aspects, like minAML
(http://www.cs.princeton.edu/sip/pub/aspects-theory.pdf) and muABC
(http://fpl.cs.depaul.edu/rjagadeesan/ftp/muABC.pdf) though I think
neither of these allows reasoning about composition.

Anyway I'd like to be involved in this

Damien

On 31/08/05, Oege de Moor <Oege.de.Moor@comlab.ox.ac.uk> wrote:
>
> Following discussions with Julian, Pavel and Neil...
>
> I've tried to think through what would happen if we took
> the "aspects are dynamic, not transformers" seriously
> in the area of aspect composition, precedence and
> hiding.
>
> Nuts?
>
> -O
>
> ==================================================
>
>
> 0. Aspect application
> ---------------------
>
> An aspect is like a process; applying an aspect to a base
> program is like putting it in parallel composition with
> a program. Aspect composition is thus a dynamic notion;
> it makes no sense to say that an aspect is applied to
> static notions like a class or a package (as one would do
> in feature-oriented programming). Instead, an aspect is
> composed with *code*.
>
> Consequently, the basic form of composing aspects with
> code should be a new form of Java statement, say
>
> with(ExAspect) {
> ... code whose execution is advised ...
> }
>
> This creates a new instance of ExAspect, and runs it to
> advise the indicated region of code.
>
> 2. Precedence
> -------------
>
> The execution model, then, is a virtual machine that keeps
> a stackof aspects. Upon every join point "enter" event,
> each aspect gets a chance to advise the join point, with
> the topmost aspect getting highest precedence. Executing
>
> with(A) { ...}
>
> pushes a new instance of A on the aspect stack, and it
> gets popped upon completion of the statement.
>
> Precedence is thus a dynamic notion, not a static one. Note
> that this decision implies th2at
>
> with(A1) { with(A2) { ...}}
>
> is *not* the same as
>
> with(A2) { with(A1) { ... }}
>
> aspect application is not commutative.
>
> To maintain the same expressiveness as we have now we
> need to assume one "MainAspect" class with an instance that
> is always at the base of the aspects stack.
>
> 3. Hiding
> ---------
>
> If we accept 1), then it is obvious that joinpoint
> hiding (and thus modular reasoning about a system)
> is not primarily a property of classes, but *of the
> aspect application operator*. Consequently, I propose
> the statement
>
> with(A) expose(pc) B
>
> which says that for the application of the instance of A,
> the code in block B will only expose joinpoints that match
> the pointcut pc; all others will be ignored by the instance
> of A.
>
> 4. TODO list
> ------------
>
> Can we express common examples of per-instantiation in
> AspectJ in these terms?
>
> Write an interpreter to illustrate the model (adapt
> Damien's version of Mitch Wand's semantics).
>
> Formulate algebraic laws for reasoning about aspect
> application (steal from CSP)
>
>
>
>
>
>

-- 
Damien Sereni
Oxford University Computing Laboratory
Wolfson Building, Parks Road
Oxford OX1 3QD
UK
dsereni@gmail.com / dsereni@comlab.ox.ac.uk
http://web.comlab.ox.ac.uk/work/damien.sereni