simple modules

Sam Tobin-Hochstadt samth at ccs.neu.edu
Sun Jan 31 18:56:01 PST 2010


On Sun, Jan 31, 2010 at 7:57 PM,  <ihab.awad at gmail.com> wrote:
> Hi Dave & Sam,
>
> First of all, this is an extremely well-written proposal and was a
> pleasure to read; thanks for putting it out there.

Thanks!

> My first set of questions are not (at least, directly) about the
> first- or second-class nature of the modules as you propose them, but
> rather about the isolation model implicit. Within each Context, naming
> a module is equivalent to reaching a shared instance of it. This
> instance must be declared at the topmost scope of the importing
> module, so it is in some sense forced on the entire lexical scope of
> that module. This means that, to achieve isolation via lexical scopes,
> we _must_ use Contexts, implying the use of async APIs. What is the
> rationale for this?

First, it's also possible to achieve isolation via lexical scope by
using functions, closures, and objects, as Dave's example shows.  Our
proposal attempts to leverage the existing facilities in EcmaScript to
achieve most of isolation, using modules for name management and
restricting the top-level lexical environment.

Second, we expect that needing to isolate untrusted code is the
uncommon case for importing a module.  Therefore, making the common
case simple implies that just using `import' should avoid the details
of isolation.  When it's important to isolate some piece of code, that
code will often be from another site, or otherwise created dynamically
from the perspective for the loading program. Therefore, we felt that
integrating isolation with the dynamic `loadModule' is the right
place.

Third, the reason the API for `loadModule' is async is that
encouraging synchronous dynamic loading on the web is encouraging
broken webapps.  However, it might not be right for `loadModule' to be
standardized in ES, as Dave mentioned, and offline applications would
want a synchronous version.

> Another, related question is how you recommend linking in things like
> the standard libraries, wherein module names referring to code
> (internal linking) are in the same namespace as module names referring
> to powerful objects provided by the platform (external linking).

So, the way I think of it, everything in our proposal is internally
linked, except insofar as a Context might specify a different behavior
for the name of some module.  I would recommend either using a
Context-style facility for preventing or limiting access to powerful
objects, as you put it, or explicit wiring together of code using
objects and functions.  This means that in the common case, where a
simple ES program doesn't deal with trust at all, the DOM and other
objects are available just as easily as they are today, but it's also
possible to enforce sophisticated security policies.
-- 
sam th
samth at ccs.neu.edu


More information about the es-discuss mailing list