2009/12/4 Alex Russell <[email protected]>: > On Dec 4, 2009, at 9:38 AM, Mark S. Miller wrote: > >> On Fri, Dec 4, 2009 at 8:41 AM, Alex Russell <[email protected]> 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.
Such a var would not pass the verifier. >> 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. Rewriters can bridge the gap between correct verifier and not-quite-correct code, by, e.g. introducing var declarations for free variables. > 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 > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
