\section{Message passing versus generic function calls}

In the above sections the ideas and examples are presented in the context
of the message passing paradigm.  However, this is not appropriate 
for languages like CLOS.
Instead, CLOS uses the concept of a generic function.  In this case a 
pure functional notation is used and one or more objects may participate
in the determination of the method to be executed.   Essentially, this is a
generalization from the single argument dynamic method selection mechanism to a 
multi-argument dynamic method selection mechanism.

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.  
Similarly, instead of individual objects receiving messages,  groups
of objects receive messages.

The essential ideas and motivations for the Law still apply in this context.
But some further motivation is needed for the generic function formulation.

The key feature of \oop\ is that we can attach functionality to data structures
to form classes.  This attached functionality (method)
is an integral
part of the class and (in most \oo\ languages) the method
can access the parts of
an object of that class 
in an easier way than other methods.  We view methods attached to a class
as having the right to access and make assumptions about the immediate 
structure of the class.  In other words, the class reveals its implementation
details to the methods attached to it.   These details should not be revealed
elsewhere.
Our Law re-affirms and extends this basic encapsulation principle 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.  Since
the method is not attached in any formal way to the classes of the arguments
the method has no right to access the implementation details of the arguments.
This does not prevent the method from sending messages to the arguments to
perform services in support of the method.
We make a big distinction between the first argument to which
a message is sent 
and the remaining arguments which act as support information.

A different situation arises with generic function call languages 
which allow several arguments
to select a method (e.g., CLOS).
There is potentially a case analysis of all
argument types to decide which method is to be invoked, i.e., the method
is attached to many classes.  If a method 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 arguments
and the classes of the
immediate subparts of the method selection 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 be restricted. The reason is that we only
want to think about a certain set of classes when figuring out which method
g will activate.  The return type of ` (h b) ' has to be a preferred 
supplier of ` f ' for the above to be in good style.

Furthermore, we want to restrict the effect of class changes.
Assume that the return type of ` h ' is Q which is a subpart type of B.
If the structure of B changes, we might have to modify ` f ' since a 
potentially completely
different method ` g ' might be selected.
If a class changes, we ideally 
only want to change methods attached to that class.
The Law strives to achieve this ideal, but does not succeed in all
casses (see the formulation of the benefits).

{\em Therefore, we view the number of method selection arguments of a function
as part of the interface of that function along with the typing information
and a formal or informal specification.}

Here we clash with the view of some of the CLOS inventors\footnote{We had
a lengthy correspondence with the CLOS community via the CLOS mailing
list.  We
gratefully acknowledge our correspondents for providing us with some
insight into the CLOS world.}.  They do not
consider the number of method selection arguments as being important
documentation nor part of the published interface of a function. 
They view the syntactic
non-distinction as an important feature of CLOS. 
%while we view the fact that
%we can have several method selection arguments as one (among many) contributions
%of CLOS. 

%We choose ``type(associated classes)'' for
%the remaining choice.

\noindent
LAW OF DEMETER (CLOS, class version)

In all methods M and all function calls inside method M, all method selection arguments
must belong to one of 
the following classes
\begin{itemize}
\item argument classes of M, 
\item slot classes of method selection argument classes of M, 
\item classes of objects created in M (directly or indirectly) or
\item classes of global variables used in M.
\end{itemize}