Subject: Re: progress on integration
From: Karl Lieberherr (lieber@ccs.neu.edu)
Date: Fri Feb 22 2002 - 11:01:58 EST
Hi Gregor:
You asked about the separate files called *.trv.
They contain, using 100% AspectJ syntax,
- traversal specifications
- class graph definitions needed to define traversals elegantly
(like intersection (&&) of traversal pointcuts)
- visitor interface names
You are right: this is just a temporary implementation
issue; however we find it useful to have all the traversal
specification info localized in a few files.
More on this in the undergraduate project:
http://www.ccs.neu.edu/home/lieber/com1205/w02/project/
Check the *.doc file.
Much more below.
>From gregor@cs.ubc.ca Fri Feb 22 01:45:24 2002
>Delivered-To: dem@ccs.neu.edu
>From: "Gregor Kiczales" <gregor@cs.ubc.ca>
>To: <lieber@ccs.neu.edu>
>Cc: <dem@ccs.neu.edu>
>Subject: Re: progress on integration
>
>I'm only looking at the part of this that is the code you really want to
>write. I want to to understand that before thinking about the current
>implementation.
>
>
>// a separate file containing traversals and class graphs
>// and references to visitor interfaces
>
>WHY IS THIS IN A SEPARATE FILE? i ASSUME THAT'S JUST A
>TEMPORARY IMPLEMENTATION ISSUE?
>
>aspect traversals {
> declare salaryTraversal : "from Company to Salary";
>
>WHY IS THE TRAVERSAL SPEC IN A STRING? IS THAT IMPORTANT?
>(I ASSUME THE FACT THAT THE TRAVERSAL KEYWORD IS MISSING
>AFTER DECLARE IS JUST A TYPO?)
You are right about the typo.
We try to encapsulate all our knowledge about traversal
specifications in the AP Library:
http://www.ccs.neu.edu/research/demeter/AP-Library/
This library contains a parser and we don't want to write
a parser again for processing the aspects.
Therefore, it is important that it is a string to have
better localization of traversal processing code.
By the way, the AP library should be useful for ASB.
>
>}
>
>// AspectJ's syntax for doing visitors
>aspect Summing {
> static int total;
> pointcut init(): target(Company) && traversal(salaryTraversal);
>
>I'M NOT SURE WHAT IS GAINED BY CODING INIT THIS WAY, AS OPPOSED TO
>JUST SETTING TOTAL TO 0 BEFORE CALLING THE TRAVERSAL. ONE THING
>THAT MIGHT BE LOSE IS THAT IT ASSUMES (IN THIS SEPARATE FILE) THAT
>THE TRAVERSAL WILL NEVER TAKE US TO A COMPANY IN THE MIDDLE.
>
> pointcut summing(Salary s): target(s) && traversal(salaryTraversal);
>
You are right. But it is important to us
that we can have many before/after/around
per traversal.
> before():init() {total=0;}
> before(Salary s):summing(s) {total += s.v;}
>
>HOW IMPORTANT TO YOU IS IT THAT SALARY IS AN OBJECT? DOES YOUR
>TRAVERSAL STUFF NOT SUPPORT VISITING NON-OBJECTS? I CAN'T IMAGINE
>THAT IN THIS EXAMPLE PEOPLE WOULD ACTUALLY HAVE A SALARY OBJECT,
>MOST PEOPLE WOULD USE AN INT WOULDN'T THEY?
>
It is not important. In DJ you can traverse to non-objects. You could say:
"from Company via Salary to int" or you can traverse to the
-> Salary,v,int edge.
> 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());
>}
>
>
>LET ME TRY MY CODE AGAIN, ADJUSTING FOR THE BIGGEST DIFFERENCE I
>CAN SEE IN THE TWO, WHICH IS WHETHER SALARY IS AN OBJECT. I DID
>THAT MY MAKING TWO ALTERNATIVE VERSIONS OF THE TRAVERSAL.
>
>I'D LIKE TO KNOW WHETHER THESE FIT YOUR MODEL.
>
>aspect SalaryTotaling {
>
> static int total = 0;
>
>
> declare traversal: visitSalaries1(int s)
> Company to int s:salary via Employee;
>
I like the use of the traversal specification to introduce
variables (s in this case).
We had a MS thesis on this in 1994.
http://www.ccs.neu.edu/home/lieber/theses-index.html (Coleman)
Instead of int s:salary, I would expect s:int.
I don't like this kind of parameterization of a traversal.
We like to parameterize traversals with higher-level artifacts
like class graphs and visitor interfaces but not with low-level int.
> before(int s): traverse(visitSalaries1(s)) {
> total+= s;
> }
>
>
> declare traversal: visitSalaries2
> Company to Salary;
>
> before(Salary s): traverse(visitSalaries) && target(s) {
> total+= s.intValue;
> }
I like this one better where the traversal is not parameterized.
>
>
> static int totalSalaries(Employees employees) {
> total = 0;
> visitSalaries(employees);
> return total;
> }
>}
>
-- Karl
This archive was generated by hypermail 2b28 : Fri Feb 22 2002 - 11:02:08 EST