On Jan 10, 2010, at 1:14 AM, Kevin Curtis wrote:
There could be some useful overlap with the http://code.google.com/p/es-lab/wiki/SecureEcmaScript
proposal and modules.
The restricted eval (esp #6) could be the core mechanism of a module
system.
Only if you insist on using eval to turn source text into code for a
module to be processed.
That is one way to do it, and code generators such as Caja can make
use of such an eval. But it's not essential to the module system's
syntax or semantics, it's an implementation detail.
If we specify by implementing modules using only code generation and
the smallest set of extensions to ES5 possible, we risk specification
leaks (e.g., over-specification), as well as missing better road-not-
taken alternatives that are possible only with native module support
(browser-based, no new eval and no code generator required).
From SecureEcmaScript proposal:
6. The top level binding of this in an evaled Program is not the
global object, but rather a frozen root object containing just the
globals defined in the ES5 spec.
For many current applications, the frozen |this| object is not
necessary or desirable in global code. The essential characteristic of
modules, isolation for each module's "inside" from unimported effects
of other modules, does not necessarily mean no mutation of primordial
objects.
Beyond isolation, it seems desirable to have true lexical scope in
modules, so that free variable uses are an error. See
http://wiki.ecmascript.org/doku.php?id=strawman:lexical_scope
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
