Sergei came to my office and convinced Theo and me
of a more acurate JPM. I think we should use this.

-- Karl
==========
Alternating Join Point Tree Structure:

CJPT = <root> CJP [<enclosing> EJPT] <contained> EJPT.
EJPT = <root> EJP <children> List(CJPT)  [<enclosing> CJPT].
EJP = <this> OBJ <args> List(OBJ).
CJP = <target> OBJ <returning> OBJ. 
List(S) ~ {S}.
OBJ = .

circular structure (if delete contained)

Environment (dynamic):
this: OBJ environment (e.g. immediate parts of this)
args: method execution environment
children: method body environment
also global environment

CJPT defines the participant graph of the LoD collaboration.
We need two attachments of this collaboration: one to a dynamic
join point model, the other to a lexical join point model.

Attachment:
correspondence:
lexical		  	dynamic
MethodDefinition	EJP
MethodCall		CJP

// Program and ClassDefinition are missing on lexical side

What is the generic Law of Demeter checker?

// bypassing -> *,enclosing,*
from {CJPT, EJPT} to CJPT // check each CJP 
  root.target is checked through root.enclosing: ok if in
    // args
    root.enclosing.root.args
    root.enclosing.root.this
    // returned by self calls
    root.enclosing.root




JPM

1. set of join points:  all the CJP reachable from a CJPT-object
over all CJPT-objects

2. Mechanism to define sets of JP

Our pointcut language:

Primitives:
if ( e ), where e is an expression involving the fields of CJP, EJP,
and CJPT, EJPT and thisJoinPoint and thisEnclosingJoinPoint: selects
all CJP in a given fixed CJPT that satisfy property e.

Operators:
||, &&, !

3. Mechanism to define advice on a set of join points

declare warning: pointcut p: String s;

print the s for every join point selected by p.