Proxies: Additional item for January Agenda
brendan at mozilla.com
Sun Jan 10 20:23:37 PST 2010
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
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
Beyond isolation, it seems desirable to have true lexical scope in
modules, so that free variable uses are an error. See
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss