Here's a problem I ran into with VisualWorks parcels just now - code that "shouldn't" be there. What do I mean by that? Well, take BottomFeeder as an example application. I ship an image with the various code components pre-loaded (there are now 31 potentially upgradable pieces). During the lifetime of a version, I release updates as new versions of the parcels, which BottomFeeder can download and load (either immediately or at startup).
Now, say we have a parcel that currently contains a method called blogBasicsPassword. In the next version of the parcel, I've renamed that method to blogBasicsBPassword (why? In this case, to affect the ordering of settings in the settings tool). When BottomFeeder gets the update, the new version of the parcel is loaded over the old version - but the old method - which does not exist in the new version - is not deleted. This is why, if you grabbed this afternoon's update you saw the username and password field duplicated in the Posting tool settings.
So what can we do about that? Well, it's a bug so far as I'm concerned, so I've reported it to engineering. In the meantime, this is Smalltalk, so we can do a field repair. Parcels have a variety of actions they can take during loading and unloading - in this case, we need an action to take place when the new version is loaded - a bunch of methods need to be deleted. The code below manages that:
BlogTools.BlogSettingsDomain class
quietlyRemoveSelector: #blogBasicsPassword.
BlogTools.BlogSettingsDomain class
quietlyRemoveSelector: #blogBasicsUsername.
BlogTools.BlogSettingsDomain class
quietlyRemoveSelector: #blogBasicsCBlogId.
BlogTools.BlogSettingsDomain class
quietlyRemoveSelector: #blogBasicsBlogId
The #quietlyRemoveSelector: method will fail silently if the method doesn't exist - which is what we want in a runtime application. Why are we sending these messages to the class? In this case, it's because they are class methods.
The end result of all this is a new rev of the parcel that cleans up its own mess. I love Smalltalk :)