Smalltalk Singleton Problem

Is this page an instance of bitrot? I believe that there are three Smalltalk implementations in general circulation in 2006: IbmSmalltalk, VisualWorks, and SqueakSmalltalk. I am under the perhaps-mistaken impression that the "stale instance" problem has been solved in each of these three -- and solved long eons ago. Specifically, in IbmSmalltalk, any change to the class definition that might cause a problem mutates and migrates the old instance to the new definition at the time the change is saved. The few cases where an instance of an obsolete class survives are caused by various pathological hanging references -- stack frames that refuse to die, stuck event propagation loops, that sort of thing. If this is a current problem, will someone please post a terse example (in Smalltalk) that demonstrates it?

I ask because I think that most of the complaints in SingletonsAreEvil are moot within Smalltalk.

-- TomStambaugh

In contrast to other languages in which there is limited persistence across program executions, in the SmalltalkLanguage the whole environment image may be persistent from one execution to the next.

Therefore a Singleton may be defined, and persists as a SoleInstance? in the environment image for a long time (weeks or years) from the point of creation.

This may cause evil problems in a dynamically evolving environment. The job of the singleton is to remain in place; it may remain quite hidden and forgotten among the thousands of objects in the environment image. If at a later date you dynamically change the behavior or structure of the class that defines the singleton, (or one of its superclasses), then the singleton (which you have probably long forgotten about), may become stale, using a new method behavior on an old data structure. Different Smalltalks vary as to how this is handled; most recompile all methods when the instance variables are changed. Working with stale instances is often supported by Smalltalk (the old implementation is marked as belonging to an obsolete class); this serves to let the problem hide, it may lead to unpredictable behavior.

Solution

Implement a clearly defined explicit hard reset procedure for each class, (class method #initialize) and for each project that is specifically responsible for forcing the system to be in a known, pre-use state with freshly instantiated singletons (ErrorSignal? instances being one example). Warning: do not use lazy initialization to initialize singletons! they must be kept on a tight leash.

CategorySmalltalk