3.15 Modules

A simple module system is provided, designed to capture the bare essentials of a collection of coherent code. The current module system is just associated with each library file for simplicity's sake. The methods provides: and requires: applied to the context will add to and check against a global features sequence respectively, and missing requirements are noted as the code is loaded. Again for simplicity, features currently contains and expects Symbols. The load: method also invokes a hook to set the currentModule in its context.

3.15.1 Types

Module

a group of objects and methods, along with some information about their definitions. Modules can also provide privacy boundaries, restricting certain methods' accessibility outside of the module.

FileModule

a module that has been built from source code from a file.

System

a collection of modules that together provide some larger service. Systems notably support operations on them to control large-scale libraries.

3.15.2 Operations

Module new

creates a new Module with no contents.

Module newLocated:

creates a new Module with the given locator (a filename produces a FileModule).

Module newForFileNamed:

creates a new FileModule for the given file name.

load

loads the module or system.

build

(re-)builds the module or system.

provide:

adds the element to the module's provision collection.

provides:

declares a collection's elements to be provided by the current module.

requires:

declares a collection's elements to be required by the current context. If any are not found, an error is raised.⁹

import:from:

adds an element to the import collection of the current module from the other one's provisions. If it's not provided by the other module, an error is raised.

importAll:from:

adds a collection's elements to the import collection of the current module from the other one's provisions. If it's not provided by the other module, an error is raised.

3.15.3 Auto-loading

The AutoLoader object manages unloaded Modules and allows them to be transparently loaded when their features are requested (via simple message-send). This mechanism relies primarily on defining methods which mimick accessors for the actual resolved object exactly, except for the fact that their action involves loading the file and then re-sending the message once that completes successfully. It is essential that the match between stub and feature be exact, since the feature itself must replace the stub once done. However, the standard protocol hides these mechanics and verification successfully, as follows:

AutoLoader readFromSourceIn:

takes a File Locator, reads the source in the file, and fills the database with mappings from the features it defines to the module representing it.

AutoLoader performScan &files:

takes a list of File Locators, runnung readFromSourceIn: on each. By default it scans a default list.

AutoLoader installReadyItems

reads definitions in the database, installing stubs for those which only take one message to resolve.

AutoLoader writeToStorage

writes its definitions to a default external database file for quick re-constitution.

AutoLoader readStorage

reads definitions from the default external database file. It will automatically calling installReadyItems.