Why are global variables *non-deletable* properties of the global object?

[Brendan Eich]

On Jun 19, 2008, at 8:40 PM, Mark S. Miller wrote:

>> Try putting this in a Firefox address toolbar:
>>
>> javascript:alert('foo' in window); var foo = 42; alert(delete foo);
>> alert(foo)
>>
>> You will get true (because the var binding -- not initialization  
>> -- is
>> hoisted to the top of the program, right after the javascript:),  
>> false
>> (because var makes a DontDelete binding outside of eval), and 42.
>
> I did. Thanks for suggesting that experiment. But given the above
> behavior, I don't understand
>
>   javascript:alert('foo' in window); var foo = 42; window.foo = 43;
> alert(delete window.foo); alert(window.foo)
>
> I get true, true, undefined.

Works correctly (true, false, 43) in Firefox 3 (try it, you'll like  
it!).

That looks like a Firefox 2 bug, probably to do with "inner and outer  
windows". Don't ask (security requirement of the DOM level 0,  
implemented similarly in IE and Firefox, IIRC coming soon to Webkit,  
very probably in Opera; but thanks for pointing this out!).


>> Using var in closures for object state has higher integrity than  
>> using plain
>> old properties. This makes closures better in addition to the name- 
>> hiding
>> (private variable) benefits.
>
> I don't understand this paragraph, and it seems crucial. Could you
> expand? Thanks.

var makes a DontDelete property, unlike assignment expressions or  
object initialisers (which desugar to assignments). This is better  
for implementations (name to slot optimizations) and for integrity  
(although without ReadOnly, the benefit is only knowing that no one  
can remove a variable from its scope object -- the value could still  
change).

It should even be possible to eval(s) in a scope with var bindings  
and be sure those vars were not removed or replaced by s.  
Unfortunately a bug in ES3 that I mentioned earlier this week allows  
s to replace a var or function its caller's scope with a function  
that s defines. This is not supported consistently or at all in  
popular implementations. It's fixed in ES4 (see http:// 
bugs.ecmascript.org/ticket/235).


> I'll probably be happy with that. But I'd like to understand the
> remaining anomaly above first. If it's considered correct, then I
> don't see how any of these benefits follow.

It's just a bug in Firefox 2.

/be