A little test

On Nov 8, 8:51*pm, VK <schools_r... (AT) yahoo (DOT) com> wrote:

[...]
*// Error # 7 Out of memory}
[...]

Yeah, such result can be seen also in the following example (I've
already showed this example here before):

b = 10;
alert(b);
delete b;
alert(b); // "b" is not defined

Next:

b = 10;
alert('b' in window); // true

Next:

b = 10;
delete b;
alert('b' in window); // false

And bellow this bug with "out of memory" is:

b = 10;
alert('b' in window); // true, OK, as above
delete b;
alert('b' in window); // true, again true? above was false

// the most buggy-thing
alert(b); // **out of memory**, not "b" is not defined

Does anyone have accurate info about what MS says about it?

On Nov 8, 6:17*pm, Asen Bozhilov <asen.bozhi... (AT) gmail (DOT) com> wrote:

What are you think about this
one:

window.a = 10;
eval('var a = 1;');
window.alert(a); //1
window.alert(delete a); //true
window.alert(a); //10

The interesting here is, how IE form Scope Chain when entering in
global execution context. I think IE when entering in global execution
context, Scope Chain contains:

Window Host <-- Global Object

Global execution context associated with Global Object for Variable
Object, and another interesting part is, how IE get properties of
`object' who referred from `window'.

There's one more interesting thing with IE's window, "window-wrapper"
and this (in role of Global). If we use IE8 debugger (in developer
tools) and test the following code (adding the breakpoint in the first
line):

a = 10;
this.b = 20;
window.c = 30;
var d = 40;

we'll see that [a] and [d] are *near* (on the same level) the [window]
object and the [b] and [c] are *in* the window - should be somewhere
in the window or [this] - but we won't see it - try to find out them -
you won't.

So, we have the structure something like this (just as we have some
that variable object which is *not* the [window] and *not* [this]):

VO = {
window: {
b: - ?,
c: - ? - where are they?
},
d: on entering - undefined, then - 40,
a: 10 - created on execution
};

This debugger's tab shows "locals" (local variables, of the "local"
execution context), and as we see - [window], [d] and [a] - are in
that "locals". The main issue - where are the [b] and [c]? Why don't
we see them in the properties of [window]? Nor in [window.window], nor
in [self], nor in [window.self.window]. And also - we don't see [d]
and [a] there.

Moreover, we can use the near tab for "watches" and add watch for the
[this] (which should be Global object) - and again - we won't find [b]
and [c] there.

The presence of some invisible VO (variable object) which is not the
Global as should be, can bee also seen in this example:

alert(e); // undefined
try {} catch (e) {}
alert(e);

Here we see, that in IE, just like with NFE (name function expression)
bugs - identifier [e] are present in the VO (but not in window, nor in
this). Actually, that's a bug as catch clause object should be added
to the front of scope chain only on execution time (and removed after
catch is finished) but not the entering the execution context time.

But the main interest here is that [e], if again to see in debugger,
is on the same level as [window] - but not *in* [window]:

VO = {
window: {},
e: ...
};

Backing to the [navigator] host object mentioned in this thread:

eval('var navigator;');
navigator = 10;
alert(navigator); // 10
delete navigator;
alert(navigator); // [object]

if we see in debugger, we see that structure:

VO = {
window: {
...
navigator: <host object>
...
},
navigator: 10
};

That's why after deleting our [eval]uated [navigator] we still see
[navigator] that is taken from the [window.navigator].

So, the idea mention by Richard seems to have sense - that there's
sort of special [[Get]] method implementation for that stuff. But I'm
not sure about that properties are copied to different object any
time.

/ds