Question

I’ve never used Smalltalk, but I’ve read a lot about it and it has always intrigued me. I’ve seen the cool demos where a program is running and simply by changing the methods of the classes the program’s objects are using alters the running program’s behavior. It’s clearly powerful stuff and I understand how that can work the way it does. What I can’t seem to nail down for certain is what happens to the existing instances of a class when you want to add, remove, or rename instance variables of that class.

I can’t imagine how one can alter the instance variables that all the classes are using in a running program and still expect the existing instances of that class to function correctly afterward. Perhaps I’m adding a new instance variable that I need to have initialized and where previously existing methods have been altered to depend on this variable. Couldn’t I end up with a horrible malfunction of any running code that has live instances of that class? Or what if the meaning of an instance variable has changed and I now expect a different kind of object to be stored there than was previously? Is there some kind of “upgrade” mechanism? Or is the usual practice to just let the previous instances crash and burn? Or is this simply a case of “we don’t do that sort of thing on running programs and expect them to survive?”

The only reasonably clean approach I can think of is that when you alter the instance variable definitions perhaps it actually creates an entirely new class and the old instances, prior to the change, continue to function just fine with the old class definition (which is now inaccessible by name since the name was redefined to the new class definition). Perhaps that is the most logical explanation – but since I haven’t found anything that directly explains this process, I figured I’d ask here and see what kind of fun information that got me. 🙂

Answer 1

According to this paper, it is like you said:

It also automatically manages class redefinition, guaranteeing system consistency in terms of object structures and preventing name conflicts, especially instance variable name conflicts. When a class definition changes, existing instances must be structurally modified in order to match the definition of their new class. Instead of modifying an existing object, the ClassBuilder creates a new one with the correct structure (i.e., from the new class that replaces the old one). It then fills this new object with the values of the old one. The ClassBuilder uses the become: primitive (cf 2.1.1) to proceed with the strutural modifications, by replacing the old objects with the new ones throughout the entire system.