[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Law of Demeter under debate



Jim Kempf is not easy to convince but so far we have never failed to
convince object-oriented programmers of the benefits of the Law. 
Each message from Jim leads to some further insight on our side.
>Since generic functions are never defined
>"on" a class (what class is the built-in generic function + defined
>"on"?) the Law of Demeter makes little sense for CLOS.
The Law of Demeter as stated in IEEE Computer, June 88, is not stated 
in CLOS terminology. Furthermore it is stated in terms of types while
on this mailing list we have only discussed the object version which
is the version of the Law to be followed conceptually. The CLOS formulation 
is given below and is the natural generalization of the IEEE Computer
formulation:

----- LAW OF DEMETER (CLOS, object version) -------------
For all methods M, all function calls inside M must use only the
following objects as method selection arguments:
- M's argument objects or
- slot values of method selection argument classes of M.
(Objects created by a method, or by functions which
it calls, and objects in global variables are viewed as 
being passed by arguments.
A method selection argument is an argument which is used
for identifying the applicable methods.)
----------------------------------------------------------

It is good to observe how one goes from message passing to generic functions:
1. Methods can be attached to several classes.
2. self is generalized to "method selection arguments".
3. instance variables become slot values of method selection arguments.

In this formulation the Law makes a lot of sense for CLOS. 

>	(defmethod sum-of-sqrt-of-difference ((x float) (y float))
>	  (+ (sqrt (- x y)) y))
>
>What about the result of SQRT? If the
>result of the subtraction is a negative number, then SQRT will return a
>complex number, and that is most decidedly *not* a float. So the generic
>function + would be applied to something which has neither an argument
>type nor is an instance variable, a clear violation.

This is not a violation. Look, SQRT returns a new object whether
it is a float or a complex number (by definition it
is a constructor function) and therefore we are allowed to use the result
of SQRT as method selection argument of +. I can see your reasoning
of considering it a violation. In the "type" version of the Law,
the return types of constructor function calls are raised to the same
level as the argument and instance variable types. In this example,
complex would be considered an argument type.

>>However, the Law prohibits functional composition of 
>>generic accessor functions.

>Since all accessor functions in CLOS are generic, this would prohibit any
>functional composition of accessor functions in CLOS. This is unrealistic,
>I think.

YOU ARE RIGHT. I did misformulate this implication of the Law. Thank you
for pointing it out. The correct formulation is:

The Law prohibits functional composition of generic accessor functions
which return objects that are not slot objects.
Remark: This will allow double nesting which is certainly needed.

>I stand by my objections.
What else can we do to convince you? 

-- Karl