Adding, deleting, and changing declarations
As with most VA Smalltalk operations, adding declarations to an existing application is normally done with the application loaded (and possibly running) in an image.
When a declaration method is saved or resaved, the user is asked to confirm that the affected namespaces should be rebuilt. It is possible to defer the rebuilding process, allowing declarations to be checked and changed before they take effect.
For declarations to take effect, the application namespace must be rebuilt. This involves processing all declaration methods for the application and its subapplications. This set of declarations, together with implicit declarations for the classes defined in the application and its subapplication, is the blueprint for the application's namespace and any pools defined within it. The rebuilding process changes the runtime structures in the image to match the blueprint. Associations for new application variables, pools, and pool variables are created and initialized according to the declarations.
Associations are removed for variables previously declared, but no longer needed. Existing nonassignable variables are initialized to match the valueExpression: in the declaration. Existing assignable variables are not reinitialized. This ensures that the state of a running application is preserved.
An application's namespace is automatically rebuilt when a class, subapplication, application, or configuration map is loaded, unloaded, or reloaded. It is also possible to manually rebuild application namespaces by selecting Make Consistent from the Applications menu of an Application Manager with the desired applications selected. This operation fails if there are errors in declarations or name clashes between declarations. If the operation fails, the namespaces are not rebuilt; they are the same as before the operation was initiated.
On loading or reloading, the rebuilding of an application's namespace is done after its toBeLoadedCode expression is executed, but before any methods are compiled. Typical toBeLoadedCode directly adds global variables and pools to the Smalltalk dictionary. If executed in an image in which there are no declarations for these application variables and pools, the bindings are created in the unmanaged namespace. Processing declarations moves associations of the same name from the unmanaged namespace to the managed namespace. Subsequent execution of toBeLoadedCode operates on the binding in the managed namespace, allowing smooth migration away from toBeLoadedCode.
Last modified date: 10/08/2020