Doug Orleans has developed a new programming language
called Socrates that supports both object-oriented
and aspect-oriented programming in a unified model.

The basic operation in Socrates is to send a message
to a list of arguments. A message send creates a decision point
that decides based on the arguments and the context which
code to execute.
The different choices of code to execute are partitioned into 
structures called branches consisting of a predicate and a procedure.

Definitions:
A decision value of a decision point D is a value 
used to select applicable branches
for D. (This is a generalization of the method selection argument concept, since other values besides
arguments may influence branch selection.) 

Explanation: In Java, the decision points are message sends
such as x.foo(). A decision value is an object in x.
Java is single-dispatch so there is only one
decision value per decision point. In multi-dispatch languages,
such as CLOS, there may be multiple decision values per
decision point. The same in dynamic dispatch languages,
such as Socrates.

The source procedure of a decision point D is the body
procedure of the branch being followed when D was created. 

The potential preferred suppliers to
a decision point D with source procedure S and previous 
decision point P are all of the following:
- the arguments of P
- return values of decision points whose previous decision point is P 
and whose decision values
are all decision values of P
- objects created during the processing of P
- the values of the free variables of S

The Law of Demeter for Socrates: 
Every decision value of a decision point D must be a potential
preferred supplier to D.

Explanation:
The LoD limits the decision values
of a decision point D: those are the values
used to select applicable branches.
Only values "closely related" to the predecessor of D
may be used.

Where are the data members?
The are covered by:

return values of decision points whose previous decision point is P 
and whose decision values
are all decision values of P

This covers "self" calls or "computed parts".

So the LoD for Socrates makes the mild assumption that for each
data member d there is an access method.
The "computed parts" then includeS the "stored parts".

How does the LoD for Socrates translate into the
LoD for AspectJ? How is the LoD for Java different from the
LoD for AspectJ?

When AspectJ uses an if-pointcut that is influenced by
an object o, then we get more preferred supplier objects
in the body of the advice.
What about other pointcuts? Pointcuts that involve an object.