[aosd-discuss] Article on Aspect Oriented Programming in Heron

[christopher diggins]

----- Original Message ----- 
From: "Gregor Kiczales" <gregor at cs.ubc.ca>
To: "'christopher diggins'" <cdiggins at users.sourceforge.net>
Sent: Sunday, February 08, 2004 5:48 PM
Subject: RE: [aosd-discuss] Article on Aspect Oriented Programming in Heron


> I suggest you read the 01 AspectJ paper, or the CACM special issue on AOP,
> or other similar material.

I have read your 01 AspectJ paper
(http://www.cs.ubc.ca/~gregor/kiczales-ECOOP2001-AspectJ.pdf) and there is
no mention of the term obliviousness. There is a reference though to Filman
and Friedman (http://ic.arc.nasa.gov/~filman/text/oif/aop-is.pdf), who
provide the following statement :

"AOP can be understood as the desire to make quantified statements about the
behavior of programs, and to have these quantifications hold over programs
written by oblivious programmers."

Clifton and Leaves 03 (
http://www.cs.iastate.edu/~cclifton/papers/TR03-01.pdf ) make the following
attributation to Filman and Friedman :

"Filman and Friedman define obliviousness as the execution of additional
aspect-oriented code, A, without effort by the programmer of the
client code that A cross-cuts."

Neither of which are very satisfactory.

A google search gives me 4 results for "obliviousness principle".

Rather than continue on this wild goose chase for a definition which does
not seem to formally exist, I think I shall rely on your definition :

> The ability of an aspect to affect classes without the class or the
classes
> clients knowing about it is a central element of AOP -- the so-called
> obliviousness property. That property is critical when aspects scale up.

These are two separate properties, 1) target class being oblivious to the
aspect, 2) the classes clients not knowing about the aspect. I think we can
agree that Heron satisfies part 1 strongly and clearly. Part 2 is less
obvious and is only partially supported (a good thing).

In order to maintain the mixin and have the new mixin type compatable with
Point, we would need cast to an interface supported by Point or more
specifically by crosscut_pt. Heron is special in that it is polymorphic only
on interfaces, there is no class inheritance whatsoever.

Our earlier example was too trivial so here is a better example, where
CPoint implements an interface IPoint. This is important so that there is no
loss between CPoint and crosscut(CPoint, ANY_CUTPOINT, ANY_ASPECT); We don't
require clients to know anything about ANY_ASPECT but we do require them to
be sufficiently prepared so as to accept a polymorphic type.

interface IPoint {
  contract
    SetX(int x);
    SetY(int y);
    GetX() : int;
    GetY() : int;
}

class CPoint {
  implements
    IPoint;
  fields
    int fx;
    int fy;
}
CPoint.SetX(int x) { fx := x; };
CPoint.SetY(int y) { fy := y; };
CPoint.GetX() : int { result := x; };
CPoint.GetY() : int { result := y; };

interface IMove {
  contract
    SetX(int x);
    SetY(int y);
}

class CLogAspect {
  implements
    IAspect;
}

CLogAspect.BeforeFxn(function f) {
  Log(f.Name);
}

CLogAspect.AfterFxn() {
  // noop;
}

typealias CC_CPoint crosscut(CPoint, IMove, CLogAspect);

client1(IPoint& i) {
  int x := i.GetX(); // Doesn't log anything
  i.SetX(5); // Logs "SetX"
}

client2(IMove& i) {
  int x := i.GetX(); // illegal! Throws compile time error, GetX is not part
of IMove
  i.SetX(12); // Logs "SetX"
}

main() {
  CC_Point x1 ~= new CC_CPoint();
  pt.SetX(4);
  pt.SetY(5);
  client1(pt);
  client2(pt);
}

I think that I have adequately satisfied the Obliviousness principle, at
least to a degree which would not inhibit the scalability of the Heron
approach to Aspect oriented programming. A crosscut point will always be
fully compatable with IPoint plus any newly introduced interfaces no matter
how many times we crosscut it with new and arbitrary aspects.

> The scheme you have seems more like just mixins, although I've never seen
a
> mixin scheme where you can cast away the mixin. I would think that would
> make for very fragile code.

I don't see how you can make that conclusion. A mixin in Heron is a form of
multiple inheritance. How could allowing a downcast lead to fragile code?

Thanks again for your continued time and input,
Christopher Diggins