[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Chapter 1 and 2 Last Chance Review
- To: pierson%mist@MULTIMAX.ARPA
- Subject: Re: Chapter 1 and 2 Last Chance Review
- From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 14 Apr 88 09:04 EDT
- Cc: skeene%STONY-BROOK.SCRC.Symbolics.COM@MULTIMAX.ARPA, common-lisp-object-system%sail.stanford.edu@MULTIMAX.ARPA
- In-reply-to: <8804132136.AA01079@mist.UUCP>
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.