[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Nesting and the Law
- To: karl lieberherr <lieber@corwin.ccs.northeastern.edu>
- Subject: Re: Nesting and the Law
- From: kempf@Sun.COM
- Date: Thu, 23 Jun 88 09:16:57 -0700
- Cc: commonloops.pa@Xerox.COM
- In-reply-to: Your message of Thu, 23 Jun 88 07:49:36 -0400. <8806231149.AA04866@corwin.CCS.Northeastern.EDU>
- Redistributed: commonloops.pa
>Jim Kempf's objections stem from a mis-understanding of the phrase
>'objects created within the method are treated as arguments'.
>Our idea is that a generic function does not neccessarily have to contain
>an explicit 'make-instance' call (or its equivalent) to cause the
>creation of a new object. If the generic function has within it
>a call to a function which returns A Newly Created object then this
>too is considered a creation of an object within the generic function.
>Consider user defined constructor functions in C++.
This isn't what your IEEE article says. On pg. 80 of the June issue in
your article, there is an example given which is claimed to be in
"poor" style that has the same structure as the examples in my note.
Translating the IEEE example into CLOS, we have:
(defmethod ref-search ((self reference-sec) (book book-identifier))
<other code>
;;The following two lines are identified in the text
;; as being in "poor" style
(search (arch-microfilm archive) book)
(search (arch-docs archive) book)
)
Granted, the text of the article does qualify the categorization of
functional composition as in "poor" style only when the returned object
is not an instance variable or argument type of the class "on" which
the method is defined. For generic functions, however, this is a
gratuitious restriction. 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 example which Jim Kempf cites as being in bad style is indeed in good
>style, for two reasons.
>
> (defmethod sum-of-sqrt-of-difference ((x float) (y float))
> (+ (sqrt (- x y)) y))
>
>1. The type of x and y is given as float. If the result of the '-' application
>is an instance of type float then, according to the Law as stated in
>IEEE Computer, June 88, this object is an instance of an argument type (float)
>and so it is a valid argument to the 'sqrt' function.
Correct.
>2. The application of the '-' to the x and y causes the creation of a new
>instance of the float class which is initialized to a value representing
>'x - y'. So calling '-' is just the same as creating a new object and
>giving the instance variables of that object some initial values depending
>on the arguments and some procedural processing. Thus the argument to the
>sqrt function is again valid.
Correct, but you missed the point. 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.
>However, the Law prohibits functional composition of generic accessor functions.
Since all accessor functions in CLOS are generic, this would prohibt any
functional composition of accessor functions in CLOS. This is unrealistic,
I think.
I stand by my objections.
jak