Why are global variables *non-deletable* properties of the global object?
brendan at mozilla.org
Thu Jun 19 23:20:51 PDT 2008
On Jun 19, 2008, at 8:40 PM, Mark S. Miller wrote:
>> Try putting this in a Firefox address toolbar:
>> You will get true (because the var binding -- not initialization
>> -- is
>> (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
> 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
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-
>> (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
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://
> 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.
More information about the Es4-discuss