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

[Mark S. Miller]

On Thu, Jun 19, 2008 at 6:33 PM, Brendan Eich <brendan at mozilla.org> wrote:
> On Jun 19, 2008, at 4:39 PM, Mark S. Miller wrote:
> How did you test?

I was indeed using the squarefree shell.


> 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.

It seems that the "var foo = 42;" created a DontDelete window.foo
property but the "window.foo = 43;" assignment somehow wiped out the
DontDelete attribute? Is this correct? Should it be?


>> I prefer FF and Safari's behavior to the ES3 specified behavior.
>
> Why? Lower integrity is not your style.

It's not yet clear to me which decision better supports integrity.


> 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.



>> Which
>> should ES3.1 and ES4 codify as correct?
>
> I don't believe you've tested what you think you tested. If you are using
> the squarefree.com then you're not testing an ES-anything-conformant global
> object implementation!

I was indeed making that mistake.


>> Should we drop the
>> "DontDelete" in the spec language?
>
> Absolutely not. Besides giving integrity guarantees to programmers, it gives
> implementations (including SpiderMonkey and JavaScriptCore) optimization
> opportunities (binding name to slot ahead of time, or on first among many
> uses).

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.


-- 
    Cheers,
    --MarkM