dherman at mozilla.com
Tue Feb 2 17:27:17 PST 2010
Not quite sure how to unpack the question. Let me try a quick sketch, at least for the simple modules system:
- a "module ID resolver" is a mapping from module ID's to module instances
- a "module context" is a set of module instances
- a "module context object" is a first-class value representing a module context
A module has at most one instance per module context, but may be instantiated separately in separate contexts. Module contexts might share some module instances; for example, the standard library might be shared. There might be a facility for explicitly constructing module contexts that share some module instances. Not sure.
Different module contexts may have different module ID resolvers, so for example it would be possible for host environments to provide a SecureESContext that didn't allow identifiers to resolve to the "filesystem" module or the "dom" module.
There would be an API for dynamically evaluating code in a given context; roughly a `loadModule' that takes a Context argument (or is a method of Context).
Does this help?
On Feb 2, 2010, at 5:03 PM, Kris Kowal wrote:
> Presuming that in the proverbial glossary a "Context" is what ES
> presently calls an execution context that has some intrinsic
> "Primordials", and a "Sandbox" is a mapping from unique module
> identifiers to modules (albeit instances or makers depending on what
> proposal you're talking about), does this proposal suggest that there
> is exactly one "Context" for every "Sandbox" and that any "module
> block statement" evaluated in a context populates the corresponding
> sandbox with a mapping from the given module identifier to the first
> class exports object of that module?
> Kris Kowal
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss