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. 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
