> Portable programs must not define methods on SHARED-INITIALIZE. TIL about this constraint and that it's only in effect when initializing classes. I think tha

> Portable programs must not define methods on SHARED-INITIALIZE. TIL about this constraint and that it's only in effect when initializing classes. I think that I understood it once I thought about it for a moment. It's possible that implementations have some of their internal code in primary methods for INITIALIZE-INSTANCE, REINITIALIZE-INSTANCE, UPDATE-INSTANCE-FOR-REDEFINED-CLASS, or UPDATE-INSTANCE-FOR-DIFFERENT-CLASS (The Four Horsemen of SHARED-INITIALIZE, if I may). If the user supplies a method on SHARED-INITIALIZE, then it's possible for this method to run between the system-provided primary method on e.g. INITIALIZE-INSTANCE and the system-provided method on SHARED-INITIALIZE. If this happens, the user-provided method cannot depend on the object being in any meaningful state: the system-provided method on INITIALIZE-INSTANCE may leave the object in some sort of half-initialized state, with the system-provided method on SHARED-INITIALIZE being meant to finish the initialization. You don't want your code to go in between these two. Hell, the MOP authors had a lot of foresight. (And experience, I guess.)