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?

Dave

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@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to