How to port old code to modules
Last updated at 10:16 am UTC on 16 May 2017
This page refers to a module system which is no longer included in the Squeak image. See now Environment.
2006
This is a brief how-to for those who want to migrate their current packages to work within the modular system.
Note: If you don't need to create DeltaModules (discontinued) you don't need the special importer, you can fileIn your code files as usual, just edit the system categories first as described under point 1.
Otherwise you will use an importer that separates file contents into modules and DeltaModules as necessary, from regular fileOuts. Classes that are located under the module that you specify will go into this module, but code that your files put into classes outside this module will be collected into DeltaModules (discontinued).
There are however things that aren't handled correctly yet, since DeltaModules don't yet support all kinds of changes. The only class extensions that are supported are methods (add/remove/change)–DeltaModules don't support class format changes yet (of any kind, including adding or removing class vars, etc.). DMs do however also allow defining module variables (add/remove/change). The DeltaModuleTests class illustrates how this is done.
Remember to save backups of your efforts before each critical step since this process is not guaranteed to be bulletproof. Especially loading source code is still slow, since code is still copied to the main changes file.
1. Preparing your code
Collect source code files (typically change sets) for all the parts that should go into your migrated package.
Now you will want to edit these files to make them proper for import into modules.
First of all, you should remove all doIts, because they will not be filed out as part of module definitions. Use initializer methods instead. (Modules shouldn't contain doIts, only code and variable definitions.)
Secondly, for all classes that you define, edit the files to make their system categories reflect their position within the module hierarchy. (See Choosing locations for your modules.) For backward compatibility, system categories are translated into module paths (and vice versa). The names in a module path are simply concatenated with dashes between them into system categories. E.g. #(Project MyGoodie) corresponds to the simulated system category 'Project-MyGoodie'. You use this scheme to edit the system categories in your class definitions to make your classes end up in the right places (and from this it follows that the system categories you specify shouldn't contain any spaces).
(dew) As an example, this code in 3.2:
CelesteComposition subclass: #AdHocComposition
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: 'Network-Mail Reader'
would need to be converted to this in 3.3alpha:
CelesteComposition subclass: #AdHocComposition
instanceVariableNames: ''
classVariableNames: ''
module: #(Squeak Network Applications MailReader)
Actually no. The above is ok too, but this is enough:
CelesteComposition subclass: #AdHocComposition
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: 'Network-Applications-MailReader'
Ie. it is enough to edit the category string only. hg
How to port old code to modules
2. Importing the converted code into the image
When you have edited your files, you import/convert them with the following message:
Repository importChangesFromFileNamed: fileName intoModuleAt: path
e.g.
Repository
importChangesFromFileNamed: 'MyGoodie.cs'
intoModuleAt: #(Project MyGoodie)
Now you'll want to file out the code, and test that filing it in under the modular scheme really works. (It most likely won't without some tweaking.)
