Proxies: Additional item for January Agenda

Brendan Eich 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  
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100110/fd337d29/attachment.html>


More information about the es-discuss mailing list