change-class dangers
change-class changes the class of the CLOS object involved; in the specification you'll see a "Notes" section that points out the problems of changing the class of an object in the presence of a smart compiler.

Experience has shown that sometimes you'll get into problems using slot-value or variables introduced with with-slots. It may appear the the EQ-ness of objects in not preserved because the compiler was "smart enough" to optimize these features, so for instance: if it's possible to access the same object (EQ) with another symbol, the compiler can return different slot-value's for the original or the other symbol. Even if they are EQ! This can be very confusing.

For instance:

(defvar *A* (make-instance 'bar)) (defmethod foo ((x bar)) (change-class x 'baz) (format t "~&from x: ~S from *A*: ~S" (slot-value x 'quux) (slot-value *A* 'quux))) (foo *A*)

Can produce output like: "from x: 1 from *A*: 2", depending on the compiler and/or optimization qualities.

To solve this just call a helper function just after changing the class. The compiler will not optimize over function calls so the slot-value and with-slots features work again.

programming tips