sequential class redefinition & obsolete instances

[Nikodemus Siivola]

  reported by Bruno Haible:
   (defclass reactor () ((max-temp :initform 10000000)))
   (defvar *r1* (make-instance 'reactor))
   (defvar *r2* (make-instance 'reactor))
   (slot-value *r1* 'max-temp)
   (slot-value *r2* 'max-temp)
   (defclass reactor () ((uptime :initform 0)))
   (slot-value *r1* 'uptime)
   (defclass reactor () ((uptime :initform 0) (max-temp :initform 10000)))
   (slot-value *r1* 'max-temp) ; => 10000
   (slot-value *r2* 'max-temp) ; => 10000000 oops...

  Possible solution:
   The method effective when the wrapper is obsoleted can be saved
     in the wrapper, and then to update the instance just run through
     all the old wrappers in order from oldest to newest.

[Douglas Katzman (dougk)]

is this actually a bug? The instance-obsolete protocol is allowed to be lazy.

*R1* took the obsolete instance trap because of SLOT-VALUE being used, at which point *R1* was obligated to discard its MAX-TEMP slot. *R2* did NOT take the obsolete instance trap at that time.
Then the class underwent another redefinition adding back the MAX-TEMP slot, but *R2* never was obligated to discard its value for MAX-TEMP. Or does AMOP actually say that the behavior of successive redefinitions is that you MUST appear to act as if each redefinition happened to every extant instance? If it says that, then the "transitivity of wrapper updates" thing in pcl/wrapper.lisp is completely wrong - you should only ever update to one more recent incarnation of the class that you have not yet updated to, and iterate as necessary.

[Douglas Katzman (dougk)]

Tried this example in 7 other implementations. All agree with SBCL - the instance obsolescence protocol does not require this behavior. Naturally CLISP disagrees, but so be it.