simple modules

Kris Kowal kris.kowal at
Tue Feb 2 18:23:55 PST 2010

On Tue, Feb 2, 2010 at 5:27 PM, David Herman <dherman at> wrote:
> 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?

> 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

Please call this something else.  It is confusing for "context" to
mean "execution context" and "module context" depending on the
"context".  I've called this a "system of modules" or "sandbox of
modules" in the past.

> 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.

This verbiage implies black-listing.  It would be good to be clear
that the object formerly known as a "module context" should be
explicitly populated with a white-list of module instances for SES.

> 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).

Tell me more about this "loadModule" and how it works.  I am concerned
that modules would be "autonomous"; I firmly believe that a chunk of
code should never select its own name, or more to the point, it should
never be necessary to edit code to give a module, or a tree of
modules, an alternate name.  That kind of coupling has wasted many
days of my time, integrating disparate projects with tight linkage.

Kris Kowal

P.S., for some liesure reading, here is the Narwhal CommonJS "module
context" implementation:

More information about the es-discuss mailing list