\section{Introduction}

In our work with \oo\ techniques we have become
interested in the issues of \oo\ programming style and preventive
maintenance of \oo\ systems.  Our initial ideas were presented in 
\cite{LHLR:law-paper} which describes a set of guidelines 
called the ``Law of Demeter''. 
This ``Law'' promotes a restriction on message
sendings to objects.  As a result of this publication we have received
much feedback as well as a detailed critique from \cite{sakkinen:law-88}.
In this paper we expand on the initial ideas and present a new perspective
with which to view the Law.  The initial papers dealt primarily with
a pure \oo\ system and here we discuss issues concerning mixed paradigm
languages (e.g., C++ \cite{stroustrup:c++}) and other variations on the \oo\ theme (e.g., CLOS \cite{clos:bobrow-88}).

   As the initial formulation of the Law was stated in the terminology
of the Demeter system, we present formulations in notation specific to
several \oo\ programming languages.  We hope that these formulations
will aid the 
understanding of the ideas and motivations behind the Law.  However,
we do not pretend to be experts in all the \oo\ programming languages
in use today and so we do not consider these formulations as cast in
concrete.  We welcome responses like \cite{sakkinen:law-88} to iron out the programming
language specific wrinkles.

   The Law of Demeter as presented in \cite{LHLR:law-paper} was proposed as one of a
number of \oop\ guidelines which we want to follow and teach.  Since our
original paper was submitted other works, e.g., \cite{johnson-foote:rules},
\cite{smith:principles},
have appeared
which deal with the issues of programming style, data 
encapsulation and preventative maintenance.  
%The \oo\ paradigm is a powerful
%one and it is clear that we are not alone in investigating how it can be
%used to its full potential.

\section{A question of notation}

It is our intention that the ideas presented in \cite{LHLR:law-paper}
and in this
paper be as generic as possible and not be bound to any particular
\oop\ language.  The Demeter EBNF\footnote{Extended Backus-Naur Form,
\cite{wirth:ebnf}.} \cite{lieber-riel:oop}
used
to describe the class hierarchies in the examples is a compact, 
programming language independent notation.  This approach of using a language definition 
language to describe class hierarchies has been lately taken up by
others (e.g., \cite{wegner:concept} and \cite{madsen-norgard:hicss-88}) 
though in a slightly 
different form.  
We use the Demeter EBNF as a high-level \oo\ data structure
description language rather than using pages of bubble diagrams or
some specific \oo\ language.  In the
Demeter system these descriptions are used directly to generate
Lisp/Flavors and C++ language specific class definition code.

%   As a further clarification of the terminology used, we will sometimes
%refer to the ``type'' of an object.
%By this we mean the class of which
%the object is an instance.  
%So a type is any concept which would translate
%into a class definition.  We distinguish this concept from the typing
%system 
%belonging to a particular object orinted programming language (e.g. int, char
%or lisp list).  We call the latter `base types'.(C++ conflict)
%This allows us to deal with
%issues concerning strictly base typed languages such as C++ and base type free
%languages such as Smalltalk.  In this terminology we can now discuss the types
%of objects in Smalltalk and Lisp/Flavors in a meaningful way.
%
%The Law in terms of Clients etc and the dependancy links between classes
%
%discussion about object creation constructor functions etc
%
%discussion about return objects from method calls and documentation
% requirements
%
%discussion of meta classes 
%
%discussion about the type version and object version
%
%discussion about the law for multiparadigm
%
%discussion about the law for multi arguement method selection.
%
%problems with the law
%
%conclusion.