On Thursday, 1 September 2016, Nicolas Cellier &lt;<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>The copy is not completely clean because this assertion then fails:<br><br>(SystemProgressMorph superclass subclasses detect: [:e | e name = #SystemProgressMorph]) == SystemProgressMorph<br><br></div>IOW, the superclass is still pointing to the old class, so any change to superclass layout won&#39;t propagate to the new subclass... Bad.<br><br></div>But there&#39;s also this possibility:<br><br>| oldClass |<br>oldClass := SystemProgressMorph copy become: SystemProgressMorph.<br>SystemProgressMorph allInstancesDo: [:e | oldClass adoptInstance: e].<br><br></div>We mutate all the instances to a class detached from Smalltalk and immune to some changes...<br></div></div></blockquote><div><br></div><div>This is an interesting idea.</div><div><br></div><div>Basically we want to prevent the existing instances to be migrated to the new class layout when we change the instance variables. One way is what Nicolas suggests, but another would be to just keep the migration from happening in the first place, in ClassBuilder. </div><div><br></div><div>Could this be a general approach? To never migrate instances that are receivers of a context? They  would still be instances of the old (now obsolete) class version. They could even be kept in a weak array to be migrated later, once the contexts are no longer active. The processes could even be restarted</div>to get rid of these contexts.<div><br></div><div>There are other Smalltalks (e.g. GemStone) that even allow different class versions to exist side-by-side. We do have class versions too, but they have only been used for migrating serialized instances when the instance variables did *not* change (which is how the need for migration is normally detected). Hmm, maybe that is actually irrelevant, just ran through my mind ;)</div><div><br></div><div>So what do you think about delayed migration of instances on the stack? </div><div><br></div><div><div>- Bert - <br></div></div>