Lasse Reichstein Nielsen wrote:
It should be false. In fact is should run slower, if anything.
The global "window" variable name is no different form "setTimeout ".
Both must be looked up in the same scope chain, ending at the global
object. After that, "window.setTime out" will do one further property
lookup on the global object, so it should take longer than just using
"setTimeout " directly.
It is not true at least for IE 5.0 or higher and Opera 8.0 or higher -
thus for 80%-90% of the browsers on the market (grace to IE). Therefore
ECMA-compliant scope schema will be rather a rare exeption than a rule
with your visitors. One can hate it, scream and cry about it :-) - but
at least she should be aware of it.
For IE and Opera "Global" object and "window" object constitute two
distinct programming scopes. Again I'm not talking about some
occasional models like Adobe SVG plugin or such.
I'm talking about the standard environment of a HTML page (XHTML is not
supported by IE and interpreted as regular HTML) with a script running
on it.
In such case we have Global scope (level of global variables ang Global
methods like escape, encodeURI etc.) and Window scope *above* it (level
of ID'entified HTML elements and window methods like setTimeout, open
etc.)
On lookup the engine search first in the Global scope, if not found
then in the window scope.
Therefore if we say declare
var setTimeout = 'foobar';
we shadow window.setTimeo ut reference (engine will find "setTimeout " in
the Global scope first thus will never look in the window scope above).
Respectively if we declare:
window['foo'] = 'bar';
and later call alert(foo) then
engine will look first in the Global scope, fail on it, then look in
the window scope and find it.
For a non-aware user the fact that:
window['foo'] = 'bar';
alert(foo); // 'bar'
may lead to the conclusion that Global scope and window scope are the
same - but nothing more far from the true than that, again - at least
for IE and Opera.
It also explain the real mechanics of possible circular reference leaks
in IE as well as explains the overall higher memory consumption by
JScript - which is *not* a memory leak but makes nervious many
developers, specially ones coming from a C++ or so background.
As I'm kind of tired of regular hysterics about "VK unbellyfeels ECMA":
here a sample and I don't care if it trigs the thinking process or the
doublethink will help as usual.
....
<script type="text/javascript">
var v1 = true;
function demo() {
var v2 = true;
alert(v1);
alert(v2);
alert(this[v2]);
alert(v3);
}
window.onload = demo;
</script>
....
<div id="v1">v1</div>
<div id="v2">v2</div>
<div id="v3">v3</div>
....
P.S. If it helped to start the thinking process (which I still hope
despite don't care too much anymore):- the next question would be: "Is
it possible and how in IE's scope model that a DOM object is still
referenced in the execution context - thus not GC-available - despite
no one JScript variable holds a reference to it?"