A Law is a Law, Guffaw, Guffaw

[Dick Gabriel <RPG@SAIL.Stanford.EDU>]

The point my Debunker team came up with is that the purpose of a law -
such as the law from Demeter - should be clearly stated. Inlining as a
means of defeating the law is only interesting because it introduces a way
to meet the letter of the law without meeting the spirit of it - by
out-of-lining.  That is, wherever there is a violation of the law, one can
repair it by introducing local methods. Therefore, I ask: What does the
law buy you, for stating law only gives no clue about objectives.

Structured programming, the inquisition of the '70's, introduced ``laws''
that required that only certain programming constructs be used.
Unfortunately I had to take exams under such inquisitors, and when asked
to render Knuth's Art of Programming algorithms into these constructs, I
always used a While loop and a Case statement: The While loop tested
whether a PC went negative, and the case statement used the non-negative
PC's to select the right statement to execute and to set the next PC.

It wasn't that I missed the point of structured programming so much as
I resented it being presented as a set of laws that guaranteed something,
when all the laws did were encourage it. What is it you encourage?

Some bright fellow hit the nail on the head on this issue in a recent
message, which I cannot locate, when he remarked that CLOS abstraction
practice required that no one know how a function is implemented, but to
only know its interface.  If you use my function, you have no business
knowing whether it's generic, let alone what methods it uses or what
method combination it uses. I will publish the interface, and you must use
it.  Maybe I'll provide a means to extend my function, and then I'll tell
more about its implementation.  I certainly reserve the right to not tell
you which arguments I use for non-trivial method selection, and to
possibly change my decision.

That is the key difference between CLOS-like object orientedness and
Smalltalk-like: In Smalltalk you know that the message gets sent to some
method/class while in CLOS you have no idea how the function is
implemented:  Because of optionals, keywords, and the use of the class
named T to ignore required arguments during method computation, there is
no guaranteed knowledge by the client of a function about the method
computation of that function or even about any aspect of its
implementation.  Therefore, the law from Demeter might not have any
reasonable application to a CLOS-style language. 

Given that there seems to have been little thought given to method
combination, given that the full implications and use of CLOS has not been
fully understood, and, well, given all of this, I recommend that your
OOPSLA paper not discuss the application of the law from Demeter to CLOS
at all. Anyway, OOPSLA seems to be a SmallTalk-and-friends conference,
so discussion of CLOS really belongs in the Lisp conferences.

			-rpg-