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

[christopher diggins]

Thank you very much for the response, the link and the inforamtion on the
resource Gregor. I have updated my article as a result.

From: "Gregor Kiczales" <gregor at cs.ubc.ca>
|The problem with mixins in this case is that:
|
|  - you'd have to have one mixin for Point,
|
|  - a separate mixin for Line
|
|  - and you'd have to edit both point and Line
|    to say they included the mixin
|
|so you wouldn't really have separated the display updating behavior into a
|single place.

The point and line would not have to be edited in Heron. I accidentally left
out a very important part of the article. Here is the missing paragraph :
"What is important to note is BeforeFxn and AfterFxn are special methods
that are always called before and after every external method invocation of
an object. A class always has a default implementation of IAspect generated
that contains no-ops."

The mixin adds a dominating wrapper class around the BASE_TYPE. You would
have to only modify the declaration of the objects point and line as follows
:

CrossCut<CPoint, CMoveAspect> pt;
CrossCut<CLine, CMoveAspect> ln;

There are several ways which the single MoveAspect can intercept the moving
functions :

class MoveAspect {
  implements
    IAspect;
  public
    HandleMove();
}

example 1) by name

  MoveAspect.BeforeFxn(function f) {
    switch(f.GetName) {
      case ("setX") {
        HandleMove();
      }
      case ("setY") {
        HandleMove();
      }
      case ("setP1") {
        HandleMove();
      }
      case ("setP2") {
        HandleMove();
      }
      case ("incrXY") {
        HandleMove();
      }
    }
  }

example 2) by function modifiers

  MoveAspect.BeforeFxn(function f) {
    switch(f.GetName) {
      if (!f.IsConst()) {
        HandleMove();
      }
    }
  }

Another different approach using Heron style "mixins" (which incidentally is
perhaps a very poor and misleading choice of name, I don't know, maybe
"dominator" would be better or perhaps "wrapper" ). Note that in the
example, we asssume that CPoint and CLine do not supply us with the IMover
interface, we add it afterwards.

  interface IMover {
    setX(int x);
    setY(int y);
    setP1(Point p);
    setP2(Point p);
    incrXY(int x, int y);
  }

  class CMoveDominator {
    implements
      IMover;
  }

  mixin<CPoint, IMover, CMoveDominator> point;
  mixin<CLine, IMover, CMoveDominator> line;

What this specifies is that we have wrapped CPoint and CLine in a new
interface IMover. When a member of IMover is invoked externally the
implementation is passed to CMoveDominator which may or may not let it pass
through. In case this wasn't fun enough we could wrap the CMoveDominator
itself in an Aspect.

  mixin<CPoint, IMover, aspect<CMoveDominator, AnnotherAspect>> point;
  mixin<CPoint, IMover, aspect<CMoveDominator, AnotherAspect>> line;

I want to verify that these examples classify as Aspect Oriented
Programming. AFAICT there is in fact a clear isolation and separation of a
cross cutting algorithmic concern.

Thanks again for taking the time to read and respond to my posts,

Christopher Diggins
http://www.heron-language.com