ServerJS/Modules/SecurableModules: Difference between revisions

no edit summary
(Added a note about ServerJS securable module identifiers.)
No edit summary
Line 1: Line 1:
This specification addresses how modules should be written in order to be interoperable among a class of module systems that can be both client and server side, secure or insecure, implemented today or supported by future systems with syntax extensions.  These modules are offered privacy of their top scope, facility for importing singleton objects from other modules, and exporting their own API.
This specification addresses how modules should be written in order to be interoperable among a class of module systems that can be both client and server side, secure or insecure, implemented today or supported by future systems with syntax extensions.  These modules are offered privacy of their top scope, facility for importing singleton objects from other modules, and exporting their own API.


# A module receives a "require" function. The "require" function accepts a module identifier. "require" returns an object containing the exported API of the foreign module. If there is a dependency cycle, the foreign module may not have finished executing at the time it is required by one of its transitive dependencies; in this case, the object returned by "require" must contain at least the exports that the foreign module has prepared before the call to require that led to the current module's execution. If the requested module cannot be returned, "require" throws an error.
# A module receives a "require" function.
## The "require" function accepts a module identifier.
## "require" returns an object containing the exported API of the foreign module.
## If there is a dependency cycle, the foreign module may not have finished executing at the time it is required by one of its transitive dependencies; in this case, the object returned by "require" must contain at least the exports that the foreign module has prepared before the call to require that led to the current module's execution.
## If a requested module does not exist, returns "undefined".
## If the requested module cannot be returned, "require" throws an error.
# A module receives an "exports" object that it may add its exported API to as it executes.
# A module receives an "exports" object that it may add its exported API to as it executes.
# Interoperable modules must use the exports object as the only means of exporting, since an implementation may prevent tampering with any other object shared among modules.
# Interoperable modules must use the exports object as the only means of exporting, since an implementation may prevent tampering with any other object shared among modules.
171

edits