Re: Chapter 1 and 2 Last Chance Review

[Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Wed, 13 Apr 88 17:36:10 EDT
    From: Dan L. Pierson <pierson%mist@multimax.ARPA>

			(2) Calls from outside the package may store incorrect
			    types (so even if your portable code is self-consistent
			    you could wind up with undetected type errors).
    
	I don't know what you mean by (2).
    
    Let's say you're implementing a window system which has slots
    WINDOW-WIDTH and WINDOW-HEIGHT.  You define these slots to be of type
    integer *and* ensure that your code never puts a non-integer in them.
    You still have to explicitly check the type of the slot value every
    time any code that you didn't write could have run because a user
    program could have put a non-integer in the slot without getting an
    error in some implementations.

OK.  You're right, you would have to do that if you want to have
portable code.    You can do it pretty easily by defining two methods
for the writer generic function yourself (instead of using an
automatically-generated method).   One method specializes the new value
parameter on integer (the desired type of value), and writes the value
into the slot.   The other method doesn't specialize the new value
parameter, so it gets selected on undesired types of values, and it
signals an error.

Or you could define a before-method on the writer that checks the type
of the new value and signals an error if it isn't an integer.   If it is
an integer, the before-method just returns and lets the primary method
write the value into the slot.

If you do this type-checking in methods for accessors, you have to 
depend on your clients calling the accessors and not using slot-value.