Addition of a global namespace function?

Alex Russell alex at dojotoolkit.org
Fri Dec 4 13:47:36 PST 2009


On Dec 4, 2009, at 9:38 AM, Mark S. Miller wrote:

> On Fri, Dec 4, 2009 at 8:41 AM, Alex Russell <alex at dojotoolkit.org>  
> wrote:
>> CommonJS modules don't solve the global pollution problem, because  
>> they can't. We're gonna keep blowing off limbs until we acknowledge  
>> that there's a design flaw in the language and take some positive  
>> action at a semantic level to correct it.
>
> ES5 allows one to enumerate all properties on primordial objects
> except the global (window) object, to attempt to delete all properties
> that are absent from a whitelist or die trying, and then to attempt
> freeze all these cleaned up primordials (including all objects
> reachable by traversal of remaining properties) or die trying. If both
> of these succeed...

...then you still can't keep someone from plunking something into  
window. for only their context. Not that you'd want to, but the  
language still makes you work harder than not to do the right thing. A  
missing "var" still screws the pooch.

> ES5-strict enables to do a fully static scope analysis. Say one builds
> a static verifier for Program text that does nothing but reject text
> that either 1) is not a valid ES5-strict program unit, 2) has free
> variables, or 3) uses a direct eval operator. A "closed function" is a
> function that has no free variables. The natural rewrite of a module
> is as the body of a closed function, perhaps packaged in a larger
> closed expression or Program that would pass the above verifier.
> Because ES5-strict is statically scoped, such a verifier effectively
> removes the global object from the bottom of the scope chain of
> Programs that pass this verifier.

Again, it's good that we can do it now, but the default policy hasn't  
changed, you you'll forgive me if I'm somewhat skeptical that opening  
the door alone will bring in the thundering herds.

Regards

> Given that primordials (other than the global object) are transitively
> frozen and that the above whitelist was adequately restrictive, each
> call of a closed function is fully isolated -- its connectivity to the
> world outside itself is fully under control of its caller. If the
> module-function's caller denies access to the global object, the
> indirect eval function, and to the Function constructor, then the
> module cannot pollute non-local state.
>
> -- 
>  Cheers,
>  --MarkM



More information about the es-discuss mailing list