\section{Anarchy: valid violations of the Law}
The Law is intended to act as a guideline and not as
an absolute restriction.  The programmer has the choice
whether to follow it or not.  In this section, we outline
a few situations when the cost of obeying the Law may be greater
than the benefits.  However, when the Law is willingly violated, the
programmer takes on the responsibility to provide future
maintainers support, with documentation, which
otherwise would have been provided by the Law.  Consider
the following prototypical method (in Lisp/Flavors) which
is in bad style:
\begin{verbatim}
(defmethod (C :M) (p )
   ( .... (send (send p :F1)  :F2) ....))
\end{verbatim}
where p is an instance of class A and F1 returns
a subpart of p.  If the immediate composition of A changes the
method M may have to change also because of F1.  Here are two
situations when it is reasonable to leave the above as it is:
\begin{itemize}
\item
F1 is intended to serve as a ``black box"  and the programmer
knows only about the types of its arguments and the return type.
In this case, the maintainer of F1 has the responsibility to ensure that
any updates to F1 are upward compatible so as not to punish any
users of the function.
\item
If run-time efficiency is important to the application, the use
of mechanisms like friend functions of C++ may be necessary. 
Friend functions should be used carefully, since whenever the private members
of a class change, the friend functions also might change.
\end{itemize}

In an application which solves differential 
equations the following definitions may occur:
\begin{verbatim}
Complex_Number = 
  <real_part> Real <imaginary_part> Real.

(defmethod (Vector :R) (c :Complex_Number)
   ( .....  
     (send (send c :real_part) 
       :project self) ....))
\end{verbatim}
The method R is in the same form as M above and is in
bad style for the same reason.  The question is whether it is important
to hide the structure of complex numbers and to rewrite the method?
In this application where the concept of a complex number is well
defined and well understood it is unnecessary to rewrite the method
so that the Law is obeyed.
   
In general, if the application concepts are well defined and the
classes which implement those concepts are stable, in the sense that
they are very unlikely to change, then such violations as the above
are acceptable.

Following \cite{hewitt:law} and \cite{sakkinen:law-88}, we introduce the concept an 
{\em acquaintance class} of a method. The motivation is to have a systematic,
compile-time enforceable control of violations of the Law. The
acquaintance classes of a method are declared in the ``heading'' of a method
and they are added to the potential preferred suppliers of the method.
When a method has acquaintances declared, the programmer is warned that there
are ``unusual'' dependencies between the classes and the compile-time
Law enforcement program has the necessary information to suppress
Law violation messages. With the presence of acquaintances we formulate
the Law (class version) as follows: In all methods M attached to class C, use only the protocol
of the following classes:
\begin{itemize}
\item
instance variable classes of C or
\item
argument classes of M, including C or
\item
classes of objects created in M (directly or indirectly) or
\item
acquaintance classes of M.
\end{itemize}

The goal is to write methods with a minimal number of acquaintances.
We can prove that any \oo\ program can be written without acquaintances
\cite{LHLR:law-paper}.

To easily check the Law at compile-time, the user has to provide the
following information for each method:

\begin{itemize}
\item
the types of each of the arguments and the result,
\item
the answer to the question: is the method a constructor, 
\item
the acquaintances.
\end{itemize}

The Law enforcement program has to keep 
track additionally of the following information
about each method:
\begin{itemize}
\item
the message sendings inside the method and
\item
the classes of the objects created by the method.
\end{itemize}