\section{Introduction}
The Law of Demeter has been introduced in \cite{LHLR:law-paper} for message
passing object-oriented languages.
The motivation for the Law and its intent are  given in that paper.
The purpose of this paper is to introduce several generalizations
and reformulations of the Law which preserve its spirit and make
it useful for many object-oriented languages.
We also discuss some implications of the Law in further detail.

\section{Alternatives}
There are two kinds of alternatives which are independent:
The first kind  of alternatives takes either an ``object'' point of view
or a ``type'' point of view. The ``type'' point of view has two sub categories,
called ``pure type'' and ``associated classes''.
The second kind of alternatives relates to the object-oriented language
technology for which the Law is formulated.
We distinguish between ``message passing'' and ``generic function''
terminology.
% Therefore we introduce $3*2=6$ different formulations of the Law.

\subsection{Object and type alternatives}

In the first set of alternatives we distinguish between
an ``object'' and a ``type'' version of the Law.
\subsubsection{Object alternative}

This is the conceptual version of the Law which is easy to remember and to
explain. 

\begin{formulation}
%We choose ``message passing'' (defined later) for
%the remaining choice:

Inside a method M attached to class C we can only send messages to
the following objects:
\begin{itemize}
\item
  an argument object of M, including the self object, or
\item
  an instance variable object of C
\end{itemize}
(Objects created by the method, or by methods which
it calls, and objects in global 
variables are viewed as being passed by arguments of M.)
\end{formulation}
By an argument object we mean an object passed by an argument. By an
instance variable object we mean the object stored in an instance variable.

We should strive to follow this version of the Law although it
is difficult to enforce at compile-time for 
even very restricted object-oriented languages. It requires an
analysis of aliases at compile-time.

Consider
\bv
;A = <x> B.
(defmethod (A :alias) (t)
  (send self ':set-x (send t ':x)))

;T = <x> B.
(defmethod (T :m2) (a)
  (send (send a ':x) ':m3))
\end{verbatim}

Is this in good style? It depends on the context. 

The following is o.k.
\bv
(send iA ':alias iT)
(send iT ':m2 iA)
\end{verbatim}

But \verb?(send iT ':m2 iA)? by itself violates the Law.
Maybe a better name for the ``object'' version would be ``run-time'' version.
Theoretical results related to the complexity of checking
the object version of the Law are given in \cite{oppen:rec-data-80}.

The formulation of the Law has to be analyzed carefully. For example,
consider a method M attached to class C. What is the difference between:
an instance variable value of C and an immediate part of self?
Which formulation should we use in the formulations of the Law?
We have decided to use the formulation using instance variables.
The motivation is as follows: Consider the method

\bv
(defmethod (construction :walk)()
  (loop for e in (send self ':child)
    do (send e ':walk)))
\end{verbatim}

Here we send a message to a subpart of self, but we don't send a message
to an instance variable object of construction. Therefore this method
violates the Law. Why is this method considered dangerous? This method
which is attached to construction makes assumptions about the
subclasses of construction. It assumes that there is a method
{\tt child} which returns a list and each element in that list
should be responsive to a method {\tt walk}.
This should only be done if it is
well justified and should be very well documented.
The above method can be written in good style as follows:
\bv
(defmethod (construction :walk)() 
  (loop for e in (send self ':child) 
    do (send self ':aux-walk e))) 

(defmethod (construction :aux-walk) (part)
  (send part ':walk))
\end{verbatim} 

\subsubsection{Type alternatives}
The type version of the Law is compile-time enforceable for useful subsets
of the underlying object-oriented languages. The type version can be
stated in terms of classes which is less stringent and in terms
of associated classes which is more restrictive and the most useful
formulation. 

\begin{itemize}
\item pure type
\begin{formulation}
%We choose ``generic function'' (defined later) for
%the remaining choice.

In all function calls inside a method M all method selection arguments
must belong to one of the following classes:
\begin{itemize}
\item
argument classes of M
\item
instance variable classes of method selection argument classes of M.
\end{itemize}
A {\em method selection argument} is an argument which is used
for identifying the applicable methods. 
\end{formulation}

Method selection arguments
are discussed further below.
This pure type formulation of the Law is easy to remember and
does not require Demeter specific terminology. However, it is much less
stringent than the object version and allows many more methods
to be in ``good style'' than the object version. The problem comes from
inheritance, e.g. it allows also instances of proper subclasses
of the argument classes to be passed in method selection
arguments of generic function calls. This reduces modularity.

The formulation 
`` ... all method selection arguments must belong to one ...''
is important. We cannot replace it by
`` ... all method selection arguments must be instances of one ...''
because of abstract classes.

\item associated classes
\begin{formulation}
%We choose ``generic function'' (defined later) for
%the remaining choice.

In all function calls inside a method M all 
method selection arguments must be instances of a class associated
with one of the following classes:
\begin{itemize}
\item
argument classes of M
\item
instance variable classes of method selection argument classes of M.
\end{itemize}
\end{formulation}
This version of the Law is the original version and comes close
to the conceptually ideal object version while being compile-time
checkable for useful classes of object-oriented programs.
\end{itemize}

\subsection{Message passing and generic function alternatives}

In the second set of independent alternatives we
discuss message passing versus generic function call formulations.

\subsubsection{Message passing alternative}
\begin{formulation}
%We choose ``type(associated classes)'' for
%the remaining choice.

In any method M attached to class C send only messages to 
instances of a class associated with one of the following
classes:
\begin{itemize}
\item argument classes of M (which includes C)
\item the instance variable classes of C.
\end{itemize}
\end{formulation}
\subsubsection{Generic function alternative}

In the message passing framework we think of a method as attached to one
class. In the generic function generalization it is natural to think
of methods as being attached to several classes.

The idea of \oop\ is that we can attach functionality to classes.
These routines (functions or procedures,
which are called methods
in several object-oriented
systems) are an integral
part of the class and can access the parts of an object of that class 
in an easier way than other functions. These functions are part of the
semantics of the class.  

Attaching a routine to a class is like giving the routine
the right to access, at a primitive level, the instance variables.  One
could achieve the same result by attaching the routine to any other class,
but accessing the required information would be less convenient.
Attaching a routine to a class in some sense reveals the 
details of the class to the function.  
Our law just re-affirms this notion and restricts the extent of the
revealed details.

In message passing languages where a method is
attached only to one class, we restrict
the message sending essentially to instance variables types of that class.
The arguments to the method act in support of the method BUT since
the method is not attached to the classes of the arguments, the method
is not an integral part of the semantics of those argument classes.
Therefore
the function had no right to access the details of the arguments 
{\em at a primitive level}.
There is a real difference between the first argument to which
a message is sent 
and the remaining arguments which act as support information.

With generic function call languages which allow several arguments
to select a method (e.g. CLOS) this is different.
There is potentially a case analysis of all
argument types to decide which method is being invoked;i.e., the function
is attached to many classes.  If a function is attached to many classes
then it is a part of the semantics of each {\em and} should be allowed 
to send messages
to instance variable types of all the classes to which it is attached.   
Any remaining
arguments are treated in the same way as the second and following
arguments in message passing languages.
We must still distinguish between the two roles played by the arguments:
the method selection role and the supporting role.

Therefore the Law for generic function call languages with several
method selection arguments, allows the programmer of
a method to look directly at the instance variables of several classes.
We have to compensate for this by restricting more than the first
argument in a generic function call:
We require that
all function calls inside a method M must have a restricted set
of objects in all their method selection arguments.

An important idea behind the Law
is that the user has only to think about the classes
of the method selection arguments and the classes of the
immediate subparts of those argument classes when reading a method.
Consider the following example:
\bv
METHOD f (a : A, b : B) : C.

... (g a (h b)) ...
\end{verbatim}
Let's assume that g has two method selection arguments. The Law requires
that the return type of h is restricted. The reason is that we only
want to think about certain classes when figuring out which method
h will activate. 

Furthermore, we want to restrict the effect of class changes.
Assume that the return type of h is Q which is a subsubpart type of A.
If Q changes, we might have to modify f since now a completely
different method might be selected.
If a class changes, we only want to change methods attached to that class.
The Law achieves this by restricting the 
types of the method selection arguments.

\begin{formulation}
%We choose ``type(associated classes)'' for
%the remaining choice.

In all function calls inside a method M all method selection arguments
must be
instances of classes which
are associated with one of the following classes
\begin{itemize}
\item argument classes of M 
\item instance variable classes of method selection argument classes of M.
\end{itemize}
	  (Objects created by the method, or by methods which it calls,
	  and objects in global
	  variables are considered as arguments.
	  A method selection argument is an argument which is used
	  for identifying the applicable methods.)
\end{formulation}
The message passing version and the generic function call 
version are closely related: Only the first argument is a method
selection argument in the message passing version.


\section{Overloading and dynamic method selection}

Dynamic method selection with respect to an argument of a generic
function means that the arguments class is used at run-time to
determine a method to call.

Let o1 (o2) be of type T1 (T2), where T1 (T2) is a class with T1'=\{T1\}
(T2'=\{T2\}). This implies that T1 and T2 are construction, repetition or
terminal classes. In this case, (send o1 ':m) and (send o2 ':m)
can be compiled into the call of two specific methods. There is no need
for dynamic method selection for the types of o1 and o2 at run-time.
We say that message name m is overloaded. We can determine at compile-time
which method should be called.

Now, assume that T1 is a class with T1' different from 
\{T1\}, i.e., T1 is an alternation
class with more than one alternative. In this case we need dynamic method
selection
at run-time to determine which method (send o1 ':m)
should execute.

Both for overloading and dynamic method selection several
arguments might be used to determine the effective method.
These possibilities are orthogonal to each other. How do they influence
the form of the Law of Demeter? It is the dynamic method selection
which has an influence on the Law.
The overloaded functions per se don't have special priviledges
regarding access to the instance variables; they are not
``attached'' to the classes of the arguments which influence
the overloading.

E.g., in C++, we have overloading
using several arguments but dynamic method selection
only for the first argument.
Therefore, the C++ formulation uses the message passing
formulation.

\paragraph{A brief comparison between CLOS and C++.}
There is certainly a huge difference between CLOS and
C++ but with respect to the Law, CLOS and C++ are not that far apart:

{\em In C++ also all arguments are used to determine which method (called 
a member function) to execute.}

The difference is that in C++ the argument types (after the first) are 
used to determine the member function at compile-time. I.e., C++ uses
static method selection for the second and following arguments.  
The first argument in a method of a derived class
is used for dynamic method selection.

In other words:
CLOS supports dynamic method selection on all required arguments, while
C++ supports dynamic method selection only on the first argument.
Both C++ and CLOS support function overloading on all required arguments.

For C++ the message passing formulation of the Law is appropriate.
We view the compile-time method selection of C++ due to overloading
as syntactic sugar. We could always rename the methods by prefixing
their names with argument types to avoid the need of overloading.
But CLOS is inherently more powerful: it does true dynamic method
selection 
on all the method selection arguments.
Therefore we need for CLOS the generalization of the Law as proposed
in the section on ``Formulation for existing languages''..


\section{The Law in mixed paradigm languages}

In languages which support both the action-oriented and the object-oriented
paradigm we have the coexistence of function or procedure calls with
message sendings or generic function calls. We can view a regular
function or procedure as a degenerate generic function with 0 method
selection arguments. Therefore the Law of Demeter does not restrict
the regular function or procedure calls inside a method.

Outside methods we disallow generic function calls, i.e., a regular
function or procedure may not contain generic function calls.

For mixed paradigm languages it makes sense to distinguish between 
types and classes. The types include:
\begin{itemize}
\item
the types of the action-oriented base language
such as character, integer, real and other types
\item the classes of the object-oriented extension.
\end{itemize}

In CLOS many but not all Common Lisp types are classes and all
classes are types.