Re: progress on integration

Subject: Re: progress on integration
From: Karl Lieberherr (lieber@ccs.neu.edu)
Date: Thu Feb 21 2002 - 23:46:23 EST

Hi Gregor:

Your sandbox is an exciting project;
you have an interesting design which is different from ours.
Here is our current thinking:

// a separate file containing traversals and class graphs
// and references to visitor interfaces
aspect traversals {
 declare salaryTraversal : "from Company to Salary";
}

// AspectJ's syntax for doing visitors
aspect Summing {
 static int total;
 pointcut init(): target(Company) && traversal(salaryTraversal);
 pointcut summing(Salary s): target(s) && traversal(salaryTraversal);

 before():init() {total=0;}
 before(Salary s):summing(s) {total += s.v;}

 int around(): init() {
   proceed();
   return total;
 }
}

// totalSalaries
class Company {
  int totalSalaries() {
          this.SalaryTraversal(); // advised by Summing aspect
          return 0;
  }
}

// calling totalSalaries
class Main { ...
    System.out.println("result = " + company.totalSalaries());
}

This is what we have currently, except that we write

 traversal(salaryTraversal)

in AspectJ using generated method names (which you rightfully
don't like; this is only temporary).

In the next phase we also put visitor interfacesinto the traversal files:

aspect Traversals {
  declare visitors : Visitor1Interface, Visitor2Interface;
  declare traversal t1(Visitor1Interface) : "from Basket to *";
  declare traversal t2(Visitor1Interface) : "from Basket to Weight";
}

This means that in one of the Java files there must be an
interface like:

  interface Visitor1Interface {
    void before(A a);
    void after(B host);
    void after(C host);
    int around(D host);
    void start();
    void finish();
  }

and then we generate the AspectJ pointcuts and advice automatically.
For these kinds of pointcuts the AspectJ notation is a bit clumsy
especially because we cannot factor out the traversal pointcut.

How does this look to you?

Our current implementation, besides the traversal(t) and crossing(e)
pointcuts does, not touch ajc. However, we use AspectJ in
an interesting way:

// This aspect just overrides the main method and generates
// a class graph of the running program. Good way of reverse
// engineering the program. The output is a class dictionary.

import edu.neu.ccs.demeter.dj.*;

aspect CreateClassGraph {
  pointcut mainpc(String [] args) : call( * main(..) ) && args(args);
  void around(String [] args) : mainpc(args){
    ClassGraph cg = new ClassGraph(true, false);
    ClassGraphListener newCgListener = ClassGraphListenerFactory.getNew();
    newCgListener.ClassGraphEvent(args, cg);
  }
}

This creates the class graph reads the traversal file
and generates AspectJ advice for the traversal.

Gregor writes: (by "other" he refers to "cflow")

 AspectJ has
 numerous other 'structure-shy' constructs, for example wildcards,
 within, target, this etc. That's what crosscutting is all about
 after all.

Yes, wildcards are another structure-shy construct that
AspectJ has. We have used them in Demeter
in the following way:

pointcut:
-> *,*,* traversal goes through any construction edge.
-> *,e,* traversal goes through any edge labeled e.
-> A,*,* traversal goes through any construction edge starting at A.

source and target of the edges can be captured and that is
similar to this and target in AspectJ.

I view target, this etc. to be of the wildcard kind. Do you agree
with that?

-- Karl

This archive was generated by hypermail 2b28 : Thu Feb 21 2002 - 23:46:31 EST