Addition of a global namespace function?

Alex Russell alex at dojotoolkit.org
Fri Dec 4 14:11:07 PST 2009


On Dec 4, 2009, at 1:52 PM, Mike Samuel wrote:

> 2009/12/4 Alex Russell <alex at dojotoolkit.org>:
>> 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.
>
> 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.

Rephrased slightly for the entertainment of 3rd parties:

  me:  the problem is that people can still omit var
  you: everyone will run it through a verifier
  me: programmers are still human, particularly web developers. They  
don't run verifiers. In general we still have the problem.0
  you: everyone will run it through a verifier
  me:  really? And if they're going to accept the constraint anyway,  
wouldn't it be better if we just created a construct where the default  
is changed?
  you: but everyone can just run it through a verifier!
  me:  um...

Lawls.


More information about the es-discuss mailing list