Last updated at 12:16 pm UTC on 28 September 2001
- may contain zero or more submodules.
- may also take zero or more other modules as "input parameters".
- will of course also have contents proper: classes, globals, etc.
Think of the parameters as imports, ie. other (external) modules that this module needs to access.
From this, a module definition has the abstract form
Module (parameters/import list) -> submodule list.
Also, these imports and submodules could be seen as the arguments and temporary variables of a method, respectively.
The reason for this format choice is that by combining elements of this single format you can define any possible structure. (This is a graph-theoretical result.) In contrast, for example single-path inheritance places a narrow restriction on how you can structure different modules wrt each other; you would soon encounter cases which couldn't be handled by such a scheme. With this format that cannot happen.
A second reason is that this format provides a simple and familiar way of thinking about module structure: Each module is composed out of submodules, together forming a tree of nested modules. This also allows for UI tools to visualize module structures in a straightforward way, either as trees or indented lists. (Imports corresponds to crossreferences in a module hierarchy.)
Inside a module, both imports and submodules are accessible by their names. Thus from code inside the module the two kinds are indistinguishable. The difference between them is that submodules are considered to be subparts of the module (ie. the module's definition), whereas parameters are not considered part of it, but as external and just made available to it. (This matters in certain cases, e.g. if you would unload a project from the image, its submodules would also be unloaded as parts of it, whereas imports would not.)
Instead of a single path of inheritance for the names available in a Module, it should be possible to delegate name lookup to any (possibly several) imported module or submodule, by marking those modules for delegation. (The present scheme is equivalent to how Self replaces s.i. with its multiple inheritance/delegation scheme, where submodules correspond to slots and delegation corresponds to marking a self slot as a parent, except in that you can delegate also to imported modules.) Simple conflict resolution can be done by specifying an ordered lookup of submodules and imports (in the order of declaration).