In this post, I made light of the new VS support for "edit and continue". There were a few responses in the comments, along the lines that it "just works". I'm sure it's a great advance - for the curly brace world. However, we've had power above and beyond that in the Smalltalk space for (literally) decades. I figured I'd illustrate with a small example.

I've mentioned that I update this server on the fly a number of times. However, I'm not sure that I've emphasized exactly what that means from a power perspective. A couple of weeks ago, I was adding support for "search by author" (for multi-author blogs). That meant modifying a class that holds cache information - rather than scan all the posts on each such search, I simply have a cache that holds the name of each file in a dictionary, keyed by the author. It's a nice, simple scheme, the same one I use to lazily cache keyword searches. In any case, here's what the definition of the cache holder looked like before I made the change:

Smalltalk.Blog defineClass: #CacheManager
	superclass: #{Core.Object}
	indexedType: #none
	private: false
	instanceVariableNames: 'categoryCache refererCache 
		cachedHTML categoryFileCache keywordFileCache 
		cacheSem refererScanner saver availableStyles  '
	classInstanceVariableNames: ''
	imports: ''
	category: 'Blog'

And then after the change:

Smalltalk.Blog defineClass: #CacheManager
	superclass: #{Core.Object}
	indexedType: #none
	private: false
	instanceVariableNames: 'categoryCache refererCache 
		cachedHTML categoryFileCache keywordFileCache 
		cacheSem refererScanner saver availableStyles authorFileCache '
	classInstanceVariableNames: ''
	imports: ''
	category: 'Blog'

The change is simple - the addition of a single instance variable. I made this change in my test server, added the code required to utilize it, and had a working modification. That's when the power of Smalltalk stepped up - I wanted to roll this change into the server.

Now, I have a lot of blogs running in the server image. Each of those blogs holds an instance of this cache class, so each of them was short the new instance variable. No problem - I pushed out the changed code on the test server, along with the full parcel (the full component that gets loaded on startup). I pushed those to my server, and then used an interface I have on the server to have it load the changed code in. What happened? Not only do all new instances of the cache object get that new attribute, but all existing instances get it as well. To make sure that the new code referencing the cache didn't blow up, all I needed was a lazy accessor:

authorCache
	^authorCache isNil
		ifTrue: [authorCache := Dictionary new]
		ifFalse: [authorCache].

That ensures that the existing instances get the right thing when the new code I added asks for the cache. Amount of server downtime? Zero. Amount of time spent doing complex object migration? Zero. That's the definition of "it just works".

Incidentally, the blog server has been running for months without any downtime. I've updated it in the way I outlined above countless times since the last time I started it up.