| << Prev | - Up - | Next >> |
ModuleModule managers grant access to modules identified by urls. Examples and more information on module managers can be found in ``Application Programming''.
A module manager maintains a module table, that maps urls to modules. To be more precise, the table maps a url to a module or to a future for a module (this is explained later).
A module manager supports the following operations:
Linking takes a url U as input and returns a module M or a future F for a module.
We say that M or F is linked from U. Most of the time we will not distinguish between M and F.
Depending on whether the module table already contains an entry for M, the following happens:
If the module table already contains an entry M for the url U, linking just returns M.
If no entry for U is available, a new future F is created and stored under U in the module table. F is returned.
As soon as the value for the future F is requested, a new thread is created that installs a module from the url U. This is called dynamic linking or linking on demand.
If under the url U a pickled functor is stored, the module is computed by first loading the functor G. Then G is applied with respect to the url U (this is explained later) which yields a module to which the future F is bound. This also explains why it is okay to not make a distinction between module and future for a module, since the distinction does not has any consequences as it comes to module access.
If the url U refers to a system module (see also Chapter 3 of ``Application Programming'') the system module is returned.
The url U can also refer to a native functor, this is described in detail in Part VI of ``Application Programming''.
Application takes a functor F and a base url U and returns a module M.
First the import urls of F are resolved with respect to the base url U. Then the resolved urls are used for linking. The returned modules are called argument modules. Then the body of the functor is applied to the argument modules.
Entering takes a url U and a module M as input.
The module M is added to the module table under U. If the module table already contains an entry for U, an exception is raised.
A module manager is implemented as an instance of the class Module.manager. The class provides methods to link and apply functors and to enter modules into the module manager's module table.
As has been explained above, each module is refered to by a url U, some of which are Oz specific in that they refer to system modules. We just say that the module has the url U.
A module name is a shortcut for a module url. The mapping of module names to full urls is explained in detail in Chapter 3 of ``Application Programming''.
Module.manager Module managers are created as instances of the class Module.manager. For predefined abstractions that are build on top of module managers see Section 2.4.
init init()
Initializes the module manager.
link link(url:+UrlVModuleR<= _)
link(name:+NameVModuleR<= _)
Links the module identified either by a url UrlV (a virtual string) or a module name NameV (a virtual string). Returns the module ModuleR (which might be a future to a module).
The argument for the module is optional, if it is omitted the module is requested immediately.
apply apply(+FunctorModuleR<= _)
apply(url:+UrlV+FunctorModuleR<= _)
apply(name:+NameV+FunctorModuleR<= _)
Applies the functor Functor, where the url UrlV (a virtual string) or the module name NameV (a virtual string) serve as base url for linking the functor's import. If neither a module name nor a url is given, the current working directory is taken as base url.
The argument for the module is optional.
Please note that the resulting module is not added to the module table, the URL argument only serves as base url for the functor's import.
enter enter(url:+UrlVModuleR)
enter(name:+NameVModuleR)
Installs the module ModuleR under the url UrlV (a virtual string) or the module name NameV (a virtual string).
Raises an exception if the module manager already has a module under that particular url installed.
link {Module.link+UrlVsRs}
Takes a list UrlVs of urls (as virtual strings) and and returns the list of modules created by linking.
All functors are linked by the same module manager, however each application of Module.link employs a new module manager. This has the following consequences:
Modules imported by several functors are shared.
Each application of Module.link links required functors anew. That is, after replacing a functor on the file system, an application of Module.link considers the new functor for linking.
Module.link is defined as follows:
fun {Module.link UrlVs}
ModMan = {New Module.manager init}
in
{Map UrlVs fun {$ Url}
{ModMan link(url:Url $)}
end}
end
apply {Module.apply+XsRs}
Takes a list of functors or pairs of urls (as virtual strings) as input. The url in a pair of url and functor describes the base url with which the import urls of the functor gets resolved. If it is missing the current working directory is used for url resolution.
Returns a list of modules computed by functor application.
Module.apply is defined as follows:
fun {Module.apply UFs}
ModMan = {New Module.manager init}
in
{Map UFs fun {$ UF}
case UF of U#F then
{ModMan apply(url:U F $)}
else
{ModMan apply(UF $)}
end
end}
end
| << Prev | - Up - | Next >> |