Module isolation

Mark S. Miller erights at
Mon Jan 11 08:38:38 PST 2010

On Mon, Jan 11, 2010 at 3:03 AM, Kevin Curtis <kevinc1846 at>wrote:

> Re isolation, sandboxing - and modules.
> Is there is a case for the ability to 'configure and freeze' a global
> object for sandboxing, SES and maybe modules. Indeed the 'restricted eval'
> can be seen as more specific case of an eval which takes a 'configured and
> frozen global' environment. With a frozen global all bindings should be able
> to be resolved at the time eval is called. Effectively, restricted evaled
> code will have 'const x = <object>' binding added to it's scope - where 'x'
> is a property from the configured global object.
> N.B - if a restricted eval takes a second param as a string to configure
> the 'global environment' for the evaled code then it would avoid the closure
> peeking issue.
> What's the "closure peeking issue"?

> A key question is how a module system (and the ECMAScript engine generally)
> parcels out access to platform objects or capabilities (like
> XMLHttpRequest). Explicity via parameter passing  or implicitly via a more
> 'dependency injection container' style using a configured (and frozen)
> 'global' object. With the latter approach the developer could configure a
> 'global' object which hides the DOM with a jquery-ish module - and all
> modules imported (including modules importing module) could use the jquery
> module without explicity importing it.
> First-class native modules would be great:
> typeof mymod -> "Module".
> Though as has noted elsewhere  - we need this functionality SRTL - it's
> crucial!
> _______________________________________________
> es-discuss mailing list
> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list