Just a random idea that been floating in my head for a few weeks... As I understand it, with Spur we can now have immutable objects. I guess this will help when a functional style programming may be useful (such as background tasks). Newly designed applications might make good use of this, but I am wondering about where you might have a large existing code base (e.g. Squeak/Pharo) and you want to background some small part of the existing code. A great effort would be needed to dig deep into object composition to understand how disparate parts of the system may hold references to object internals several layers down, that may get updated unexpectedly. So I am wondering if instead / or as well as object-immutability it is feasible to get thread-immutability, meaning: * writing to any object state is prevented - which prevents the background thread changing the foreground (UI) state unexpectedly; and/or * reading or writing any object automatically sets its immutability bit - which prevents other unknown threads changing the state the background thread has come to rely on. No doubt pushing any existing single-threaded code into such a background immutable-thread will cause immutablity-write-errors - but the advantage is that such conflicts are brought to light rather than biting you from the shadows. cheers -ben