kevinc1846 at googlemail.com
Mon Jan 11 03:03:18 PST 2010
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss