The typical SmalltalkLanguage installation comes with implementation of most builtin classes (e.g.: iterators, windowing/graphics, exceptions, and the object model itself) exposed for edits.  Sometimes it is tempting to use this power.

Examples:
	* RefactoringImprovingTheDesignOfExistingCode teaches us about "ForeignMethod''''''s".  Why not put methods where they belong, even if they belong on existing classes?

	* In the PluggableWebServer, you're told to configure some defaults ("Document Root", etc.) by editing a class.

	* Sometimes you'll find apparent bugs or surprising behaviors.

	* Sometimes it looks like fun.

'''However,'''

There are significant downsides to this:

	* If the vendor updates the code, you're either stuck with the old version or forced to manually merge the changes.

	* You could change something that subtly makes your environment incompatible with others'.  Yikes!

After all, you wouldn't change parts of your C library's implementation... would you?

'''Solutions:'''

The general solution is to combine UnitTest''''''s with an edited copy of your change.log -- or a fileout of your code.  Remember that in Smalltalk you can always overwrite any class code with new changes -- this is the way that we used to distribute smalltalk "Addon" products.  You still have to manually merge your changes back in, but that's something that a changes browser will help you with.

Another approach is to issue new developers two or three tokens with the stern warning that each system modification will cost them one, and that they can only be replenished by shipping successful projects. 

----
CategorySmalltalk