[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Law and localization
- To: commonloops.pa@Xerox.COM
- Subject: Law and localization
- From: karl lieberherr <firstname.lastname@example.org>
- Date: Thu, 23 Jun 88 08:45:24 EDT
- Redistributed: commonloops.pa
John Rose writes:
Try a negative formulation. It seems like you are allowing
every kind of argument __except__ those that potentially break
abstraction boundaries. Classes local to the method are deemed
to drop their abstraction boundaries inside the method.
For me, the key illuminating comment on your Law was this:
The idea is that it is a bad strategy to put a dependency on the
C class into this method which is "attached to" A and Z.
This is a start at a negative formulation, which is why it helped me.
It was interesting to hear what the illuminating point was for you. Here is
an attempt at a negative explanation:
A generic function has the authority to make decisions and operate
in ways which are DEPENDENT on the 'valid' method selection objects
(argument objects and slot values of method selection arguments) and their
types, but IS NOT ALLOWED to be dependent on the sub-parts of those objects.
The deep structures of the objects are hidden from the generic function.
John Rose writes further:
General problem: When a representation changes, what pieces of
code need to be recompiled? Or possibly rewritten? It looks
like this Law is intended to keep these sets of code pieces
small and easily determinable. "Small" I think is a good goal;
"easily determinable" is not so important.
Well, easily determinable is also important since the program will be
read and understood by humans. I agree that a good tool makes the
"easily determinable factor" less important.
John Rose asks the following question:
Consider this code:
(DEFCLASS X () (X-SLOT))
(DEFCLASS Y () (Y-SLOT))
(X (SLOT-VALUE MY-X-OR-Y 'X-SLOT))
(Y (SLOT-VALUE MY-X-OR-Y 'Y-SLOT)))
It seems to me that this code is as semantically clean as the
equivalent formulation with methods:
(DEFMETHOD INSTEAD-OF-TYPECASE ((MY-X-OR-Y X))
(SLOT-VALUE MY-X-OR-Y 'X-SLOT))
(DEFMETHOD INSTEAD-OF-TYPECASE ((MY-X-OR-Y Y))
(SLOT-VALUE MY-X-OR-Y 'Y-SLOT))
I think the TYPECASE formulation is better style, don't you?
No, I don't. The TYPECASE solution is less modular than the
formulation with methods and is harder to maintain. When
you add a class Z, you have to MODIFY code in the TYPECASE solution
while in the good solution you only have to ADD code.
Indeed, you can view the TYPECASE macro solution as violating the spirit of
the Law of Demeter. Assume that the TYPECASE is in a method. The TYPECASE
uses a generic function which returns the type of its argument.
This object is then compared by a generic equality function with
a class name. But the type returned is not a new object (it can be viewed
as a part of the given object), and therefore we are not allowed to use it
as method selection argument in another generic function call.