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:

'((cl :mode :display) (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