Sometimes, when I have a modification I think would be useful for BottomFeeder, I figure it would make sense to try it out in a runtime environment before I send it off as an update. I can package the thing up as a parcel and simply load it into my application, of course - I just open the System>>Execute Smalltalk Code menu item, and enter the following into the workspace:

Parcel loadParcelFrom: 'ParcelNameHere.pcl'.

I highlight that and execute, and then answer "yes" to the confirming dialog (which pops because I'm reloading a new revision of a parcel that's already loaded). Other times, I want to try a smaller modification - a few method changes (which, if they work out, I'll package as an update. In that case, I export the modified code from my development environment as a fileout, and then execute this in a workspace in the runtime:

'FilenameHere.st' asFilename fileIn.

That loads the small change. If it's something that shouldn't go into production, but that I'd like to load at startup anyway, I can save the new file into the BottomFeeder directory, and just slap the code above into the .btfrc file (which gets auto-loaded at startup, if it's there).

The cool thing about all this is that Smalltalk provides its own scripting language. I ship BottomFeeder with the compiler and workspace present so that I can experiment like this, and also so that other people with Smalltalk knowledge can dive in, if they want to. Unlike a Java application, I don't have to tell people to use a "simpler" scripting language - which, btw, should be a sure sign that there are problems in Java - if the base language is too complicated for that task, that's a problem - at least IMHO.

In any event, it's a neat thing about Smalltalk - and it's something that allows customization of a runtime application, if the developer(s) of that application want to allow that.