In traditional Smalltalks, all the method objects have a shared object representing the file that method source is stored in (either .sources or .changes, with

In traditional Smalltalks, all the method objects have a shared object representing the file that method source is stored in (either .sources or .changes, with room for more) and an offset in the method to point to the text. On compilation, all it does is write the new method with metadata to the end of the .changes file, then set the text indexes. There is a mechanism to crunch out all the unused source text and generate a new merged .sources file. If you are all working on the same base version, .sources files can be shared since they are usually read only. The nice part of doing this is you don't have to use much core for the method source, which was a big deal in 1978. You can easily strip the sources and changes files if you don't need them. eg. when distributing a build to customers. It also lets you remember the change history and enables recovery from crashes and other errors. The basic mechanism is also fairly easy to repurpose to support other change tracking approaches. The interesting trick, is if you don't have a .sources or .changes, the system will run the Decompiler, which almost always produces readable code that is structured like the original source but with no comments and the local variable names changed to t0, t1, t2,... etc. There have been proposals to keep local var names in the image as to make it a bit less painful. It is surprisingly easy to code like this. There have also been proposals to store the whole source text in the image. You could do it and it wouldn't be hard, but you'd lose the advantages of the external code storage. This does not count the various project facilities and change lists so you can keep related changes grouped.