@TECHREPORT{TR-theo-jeff-karl:sep-2005,
AUTHOR = "Therapon Skotiniotis and Jeffrey Palm and Karl J. Lieberherr",
TITLE = "Demeter Interfaces: Adaptive Programming without Surprises",
INSTITUTION = "Northeastern University",
YEAR = 2005,
MONTH = "September",
NUMBER = "NU-CCIS-05-08"
}

@INPROCEEDINGS{theo-jeff-karl:ecoop06,
AUTHOR = "Therapon Skotiniotis and Jeffrey Palm and Karl J. Lieberherr",
TITLE = "Demeter Interfaces: Adaptive Programming without Surprises",
BOOKTITLE = "European Conference on Object-Oriented Programming",
YEAR = "2006",
ADDRESS = "Nantes, France",
PAGES = "477-500",
PUBLISHER = "Springer Verlag Lecture Notes"
}

ECOOP 2006 paper

Paper and Talks .

Notes by Karl:

This paper builds on Theo's experience of implementing design by contract
for aspects using DemeterJ. The need for interfaces became very clear.
The same issue when you look at the DemeterJ implementation.
There are implicit interfaces that really need to be made explicit.

Future work:
allow richer traversal language, including primitives from XPath,
such as .. and [].

check substrategy property

Refinement of strategies
========================

There are two mappings involved when we map a class graph 
(e.g., an interface class graph) to another class graph
(e.g. a concrete class graph). 

The first mapping is mapping the terminology
of the source class graph to the terminology of the target class graph.
The first mapping is a mapping that maps nodes to nodes and edges to edges.

The second mapping maps traversal strategies in the source
class graph to traversal strategies in the target class graph.
This is done by first applying the terminology mapping
and then refining the strategy.

For example, the strategy in the source class graph is 
{ESystem -> DThing}. After the terminology mapping it is:
{EquationSystem -> Variable}. Now we refine this strategy to:

from EquationSystem via ->*,lhs,* to Variable

or to

from EquationSystem to -> *,lhs, Variable
(yes, we can go to an edge).

The meaning of those refinements is however different.

To define the second mapping precisely, we need to 
define the notion of strategy refinement. s1 is a refinement of s2
if PathSet[G](s1) is a subset of PathSet[G](s2).

Does the notion of roles added to strategies help with AP?
Only if we arrive at a node in a certain way we want to execute certain
code.

http://www.ccs.neu.edu/research/demeter/course/f97/lectures/powerpoint/lec7.ppt#27

Advice will get more involved:

void r_before_role1(Host host) {code}
// if we visit the host in role1, execute code

April 2008. DemeterF has been created. What are useful use cases for constraints and Demeter interfaces in DemeterF? In the current DemeterF, for type-checking reasons, all strategies are of the form "from A bypassing ... to B" where B may be *. Legality of a path reduces to a check that certain nodes and edges don't appear. What kind of DemeterF programs rely on the property that there is at least one B reached at run-time?