EcmaScript: delete operator

[abozhilov]

E262-3 edition
11.4.1 The delete Operator
The production UnaryExpression : delete UnaryExpression is evaluated
as follows:
1. Evaluate UnaryExpression.
2. If Type(Result(1)) is not Reference, return true.
3. Call GetBase(Result(1)).
4. Call GetPropertyName(Result(1)).
5. Call the [[Delete]] method on Result(3), providing Result(4) as the
property name to delete.
6. Return Result(5).

I don't understand something about the delete operator.
If i have code like this.

window.foo = {};
var bar = foo;
delete window.foo;
alert(window.foo);
alert(bar);

1. Attach `foo` property to Global Object. assigned to `foo` reference
to `object`.
2. Copy reference from `foo` and assigned to bar.
3. delete window.foo, will be delete `foo` property. Just delete
reference to `object`.
4. Results will be `undefined`. Logical.
5. Results will be `[object Object]`


What do `delete` operator when i delete reference? Just marked
`object` to garbage collection, if doesn't have any other reference to
that `object` in any scope? In my case created object from that line:

window.foo = {};

That object will be deleting after reload my page. Not reference, i
talk about `object`. Because i have reference to that object in global
scope:

var bar = foo;

If i have code like this:

window.foo = {};
(function()
{
var bar = foo;
delete window.foo;
alert(window.foo);
alert(bar);
})();

When `object` will be deleting? The last reference to that object is
in the anonymous function scope. I thing after executing anonymous
function that object will be delete. Because `bar` variable have local
scope.

Thanks.

 

[John G Harris]

What do `delete` operator when i delete reference?

<snip>

The 'delete' operator deletes an object property. If the property's
value happens to be a reference to an object then that object is not
changed.

There is no way in javascript to delete an object. All you can do is
remove all references to it. The garbage collector will destroy the
object when it needs the storage space for something else. Possibly the
garbage collector will destroy the object sooner than that, but it isn't
guaranteed. You've no way of finding out which happened.

John

 

[Thomas 'PointedEars' Lahn]

E262-3 edition
11.4.1 The delete Operator
The production UnaryExpression : delete UnaryExpression is evaluated
as follows:
1. Evaluate UnaryExpression.
2. If Type(Result(1)) is not Reference, return true.
3. Call GetBase(Result(1)).
4. Call GetPropertyName(Result(1)).
5. Call the [[Delete]] method on Result(3), providing Result(4) as the
property name to delete.
6. Return Result(5).

I don't understand something about the delete operator.
If i have code like this.

window.foo = {};
var bar = foo;
delete window.foo;
alert(window.foo);
alert(bar);

1. Attach `foo` property to Global Object. assigned to `foo` reference
to `object`.

No. How and where did you get the idea that the host object referred to by
`window' would be generally identical with the native ECMAScript Global
Object? Evidently it isn't, and because it is a host object you should not
attempt to augment it with user-defined properties.

Use `this' in the global execution context to refer to the ECMAScript Global
Object.

2. Copy reference from `foo` and assigned to bar.

I would not use the word "copy" here. The reference is a *value* and so
simply assigned (read from A, written to B). Think of it as a number, say
42; that will make things easier to understand.

3. delete window.foo, will be delete `foo` property.

Which *might* delete the `foo' property. You are dealing with a host object
here. See below.

Just delete reference to `object`.
No.

4. Results will be `undefined`. Logical.

The result is `undefined' because there is not a property with such a name
anymore; _not_ because the reference was deleted. The reference is a value
and may well continue to exist in memory without being accessible by code.

5. Results will be `[object Object]`

As the string representation of (Object) objects is not specified or fixed,
the result may be anything here. In particular, the string representation
of an object is known to be implementation-dependent.

`alert()', or better `window.alert()', is not a suitable means to detect
anything if you don't know what you (and it) are doing.

What do `delete` operator when i delete reference?

The `delete' operator deletes properties from objects, not references.

Just marked `object` to garbage collection, if doesn't have any other reference to
that `object` in any scope?

If, before the deletion attempt, the property stored an object reference,
the object being referred to is going to be marked for garbage collection
iff that was the last reference to that object (much like a hardlink in the
filesystem).

In my case created object from that line:

window.foo = {};

That object will be deleting after reload my page.

*Maybe*. First of all, `window' refers to a host object; second, garbage
collection is entirely at the disposal of the implementation.

Not reference, i talk about `object`. Because i have reference to that
object in global scope:

var bar = foo;

The global `bar' variable is a property of the global Variable Object, which
is the ECMAScript Global Object. Whether that object is destroyed *before*
reload, and the memory allocated for storing its properties is freed,
depends on the implementation and on the runtime environment it is used by.
Logic and experience suggests that at least all its properties are deleted
before reload.

If i have code like this:

window.foo = {};
(function()
{
var bar = foo;
delete window.foo;
alert(window.foo);
alert(bar);
})();

When `object` will be deleting?

At some unspecified point in time after the `delete' operation, hopefully.
However, the property will be deleted immediately, unless the host object
referred to by `window' does not allow it, or the property may have, despite
its being user-defined, the `DontDelete' attribute (as a host object, the
object referred to by `window' may implement a [[Put]] or [[Delete]] method
that does not follow the specified ECMAScript algorithms).

The last reference to that object is in the anonymous function scope.
I thing after executing anonymous function that object will be delete.
Because `bar` variable have local scope.

The object might be marked for garbage collection then. That is quite
different from deletion in the sense of deallocation, which happens at some
point in time later, hopefully.


PointedEars

 

[abozhilov]

No.  How and where did you get the idea that the host object referred to by
`window' would be generally identical with the native ECMAScript Global
Object?  Evidently it isn't, and because it is a host object you shouldnot
attempt to augment it with user-defined properties.

Use `this' in the global execution context to refer to the ECMAScript Global
Object.

See also: <https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference>

In this case, you are absolutely right. That is my error. My web
development bending. Thanks. This is good point. "this" keyword is
best in this case to referred Global Object.

I would not use the word "copy" here.  The reference is a *value* and so
simply assigned (read from A, written to B).  Think of it as a number, say
42; that will make things easier to understand.


Which *might* delete the `foo' property.  You are dealing with a host object
here.  See below.


The result is `undefined' because there is not a property with such a name
anymore; _not_ because the reference was deleted.  The reference is a value
and may well continue to exist in memory without being accessible by code..

Exactly. That i want to say. Just illustrate what been deleted from
`foo` property. The delete operator simply delete property from
`object`.

5. Results will be `[object Object]`

As the string representation of (Object) objects is not specified or fixed,
the result may be anything here.  In particular, the string representation
of an object is known to be implementation-dependent.

`alert()', or better `window.alert()', is not a suitable means to detect
anything if you don't know what you (and it) are doing.

In this case you are right. But if i use.
Object.prototype.toString. We get internal [[Class]] property.
In my case:
alert(window.foo);
equivalent to:
alert(window.foo.toString());
If someone predefined toString method of that object, we have another
results. In this case you are absolutely right.
Again good point.

What do `delete` operator when i delete reference?

The `delete' operator deletes properties from objects, not references.

Just marked `object` to garbage collection, if doesn't have any other reference to
that `object` in any scope?

If, before the deletion attempt, the property stored an object reference,
the object being referred to is going to be marked for garbage collection
iff that was the last reference to that object (much like a hardlink in the
filesystem).

In my case created object from that line:

window.foo = {};

That object will be deleting after reload my page.

*Maybe*.  First of all, `window' refers to a host object; second, garbage
collection is entirely at the disposal of the implementation.

Not reference, i talk about `object`. Because i have reference to that
object in global scope:

var bar = foo;

The global `bar' variable is a property of the global Variable Object, which
is the ECMAScript Global Object.  Whether that object is destroyed *before*
reload, and the memory allocated for storing its properties is freed,
depends on the implementation and on the runtime environment it is used by.
 Logic and experience suggests that at least all its properties are deleted
before reload.

If i have code like this:

window.foo = {};
(function()
{
   var bar = foo;
   delete window.foo;
   alert(window.foo);
   alert(bar);
})();

When `object` will be deleting?

At some unspecified point in time after the `delete' operation, hopefully..
However, the property will be deleted immediately, unless the host object
referred to by `window' does not allow it, or the property may have, despite
its being user-defined, the `DontDelete' attribute (as a host object, the
object referred to by `window' may implement a [[Put]] or [[Delete]] method
that does not follow the specified ECMAScript algorithms).

The last reference to that object is in the anonymous function scope.
I thing after executing anonymous function that object will be delete.
Because `bar` variable have local scope.

The object might be marked for garbage collection then.  That is quite
different from deletion in the sense of deallocation, which happens at some
point in time later, hopefully.

PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
)  // Plone, register_function.js:16

After your post my example look like this:

this.foo = {};
var bar = this.foo;
delete this.foo;
alert(this.foo);
alert(Object.prototype.toString.call(bar));

Thanks Thomas for your usefully posts.

 

[Thomas 'PointedEars' Lahn]

5. Results will be `[object Object]`

As the string representation of (Object) objects is not specified or fixed,
the result may be anything here. In particular, the string representation
of an object is known to be implementation-dependent.

`alert()', or better `window.alert()', is not a suitable means to detect
anything if you don't know what you (and it) are doing.

In this case you are right. But if i use.
Object.prototype.toString. We get internal [[Class]] property.

Iff the specified algorithm is used; you cannot know that, not even if you
explicitly call Object.prototype.toString(). That is, if the object
implements its own toString() method or is a host object, the string
representation would not be known. And however unfortunate and apparently
not standards-compliant, an implementation may even defined its own
Object.prototype.toString() algorithm that contradicts what is specified.
Only time will tell if there is such an implementation that needs to be
taken seriously.

Thanks Thomas for your usefully posts.

You are welcome. But *please* trim your quotes to the necessary *minimum*
to retain context; do _not_ quote signatures (unless you are referring to them).

See also: <http://jibbering.com/faq/#posting>


PointedEars

 

[Jorge]

(...)
alert(Object.prototype.toString.call(bar));

=== alert( ({}).toString.call(bar) );

 

[Garrett Smith]

[...]

In this case you are right. But if i use.
Object.prototype.toString. We get internal [[Class]] property.
In my case:
alert(window.foo);
equivalent to:
alert(window.foo.toString());

The |window.alert| method (nonstandard) converts its argument to a
string. Following the internal [[ToString]], alert(foo) would have the
same outcome as alert(foo.toString()). Identifier |foo|'s |toString|
property is resolved up the prototype chain to |Object.prototype.toString|.

So essentially, you are correct in the object's toString being called.

Garrett

 

[abozhilov]

=== alert( ({}).toString.call(bar) );

I don't need this short optimization. I don't need to create new
Object. Object.prototype is static object and he been initialized.

({}).toString.call(bar)

First of all, you create ({}) here new object. Not assigned reference
to any variable. You used directly and that object will be marked to
GC, after executing `toString` method. And that object provide you
reference to Object.prototype `object`. This is exactly the same like:
Object.prototype.toString.call(bar);
But in this case, i don't need to initialize new `object`.

Regards.

 

[Thomas 'PointedEars' Lahn]

(...)
alert(Object.prototype.toString.call(bar));

=== alert( ({}).toString.call(bar) );
[...]

I don't need this short optimization. I don't need to create new
Object. Object.prototype is static object and he been initialized.

There is no such thing as a "static object", and certainly
`Object.prototype' is not an object; it refers to one, but
again that object is not in any sense "static".

({}).toString.call(bar)

First of all, you create ({}) here new object.
Correct.

Not assigned reference to any variable.

Correct. Your point being?

You used directly and that object will be marked to GC, after executing
`toString` method.

Correct. Your point being?

And that object provide you reference to Object.prototype `object`.

No. That object inherits from the object that `Object.prototype' refers to,
through its prototype chain.

This is exactly the same like:
Object.prototype.toString.call(bar);

No. At least in JavaScript 1.8.1 as of Firefox/Iceweasel 3.5.1, by contrast
the Object Initializer creates a new object using the original Object
constructor, regardless of the value that `Object' has been assigned. (ES3F
is ambiguous here in section 11.1.5, it says "Create a new object as if by
the expression `new Object'" without saying whether `Object' means the
original value; apparently, the Mozilla.org people thought of it as meaning
the original value.)

Test case:

Object = function() {
this.bar = 42;
};

/*
* in JavaScript 1.8.1:
* string representation of the value assigned before
*/
String(Object)

/* in JavaScript 1.8.1: "undefined" */
typeof {}.bar

In addition, your approach uses three lookup operations and two calls
through the call() wrapper, while Jorge's approach uses only two lookup
operations and two calls.

It remains to be seen which approach is more memory-efficient, and which one
more runtime-efficient; I would assume that Jorge's approach is more
runtime-efficient (as more of the work would be done internally), but less
memory-efficient (as a new object is created each time) than yours.

There is a third approach that tries to get the best of both worlds: Create
and initialize the "empty" Object object only once, and reuse it later.

But in this case, i don't need to initialize new `object`.

Apparently, if you want to be on the safe(r) side, you do. (What exactly do
you mean by "`object`"?)

Please trim your quotes, don't quote signatures.


PointedEars
___________
¹ <http://PointedEars.de/es-matrix#features>

 

[abozhilov]

(...)
alert(Object.prototype.toString.call(bar));
=== alert( ({}).toString.call(bar) );
[...]

No.  At least in JavaScript 1.8.1 as of Firefox/Iceweasel 3.5.1, by contrast
the Object Initializer creates a new object using the original Object
constructor, regardless of the value that `Object' has been assigned.  (ES3F
is ambiguous here in section 11.1.5, it says "Create a new object as if by
the expression `new Object'" without saying whether `Object' means the
original value; apparently, the Mozilla.org people thought of it as meaning
the original value.)

This is usefully example. If i want to create clean `object`, this
approach looks save to do it.

In addition, your approach uses three lookup operations and two calls
through the call() wrapper, while Jorge's approach uses only two lookup
operations and two calls.

After worked day. When i come back to my home, i thing about your
words. And:

(as more of the work would be done internally)

Object.prototype.toString.call

I want to know how many lookup operation make JavaScript. I thing in
this case lookup's is: 5.
Object constructor itself is instance from Function object. In ECMA:
15.3.2.1
A prototype property is automatically created for every function, to
provide for the possibility that the function will be used as a
constructor.

My thing about lookup in:
Object.prototype.toString.call

1. Get reference to Object constructor `object`.
2. Because prototype property is "Object instance property", from
reference of point 1. JavaScript get `prototype` property of `object`,
whos point 1 referred. Here we don't have lookup in prototype chain.
3. Point 2 again is reference to `object`. toString function object is
defined directly in `object` who referred from point 2.
4. toString itself is instance from Function object. Interesting in
this case is `call` method. He is not defined directly in `object` who
reffered `toString`. Here JavaScript check and lookup to protototype
chain for `call`.
5. call is defined in toString constructor prototype.

({}).toString.call
({}) - This will be return reference to created object from {}
1. toString isn't defined in `object` referred from {}. Lookup in
prototype chain.
2. toString is defined in {} constructor prototype.
3. Point 4 from Object.prototype.toString
4. Point 5 from Object.prototype.toString.call

There is a third approach that tries to get the best of both worlds: Create
and initialize the "empty" Object object only once, and reuse it later.

Yes, or maybe directly caching reference to:

var foo = Object.prototype.toString;

Apparently, if you want to be on the safe(r) side, you do.  (What exactly do
you mean by "`object`"?)

When i use `object` i don't talk about reference to `object`. I talk
about `object` who been referred.

Please trim your quotes, don't quote signatures.

Do you like that? With argumentation line and trim quotes.

Thanks a lot.

 

[Garrett Smith]

(...)
alert(Object.prototype.toString.call(bar));
=== alert( ({}).toString.call(bar) );

[...]

[...]

A quick test in FF3.5.2, for example, shows:

var o = { }, lim = 100000;

console.time(1);
for (var i=lim; i--; ) Object.prototype.toString.call(o);
console.timeEnd(1);

console.time(2);
for (var i=lim; i--; ) ({}).toString.call(o);
console.timeEnd(2);

1: 183ms
2: 278ms

Using a new file, with that code in a SCRIPT tag:
1: 26ms
2: 35ms

Object.prototype.toString.call is faster.

Firebug execution is not the same as global execution context.
Performance is affected. Firebug code is interpreted as differently, too:-

a();
function a(){return 1;}

ReferenceError: a is not defined

The same error is produced if |function a| is interepreted as a
FunctionStatement (Spidermonkey extension). We can test this by placing
|function a| in a block:-

{
a();
function a(){return 1;}
}

ReferenceError: a is not defined

So whatever Firebug is doing with your code, it is not running it as
ProgramCode.

A Firebug quick test (not really a test) could be made less skewed by
having the entire test wrapped in a function, so it runs as
FunctionCode, declaring |Object| in the same scope, to mitigatewhatever
Firebug does with the scope chain, plus the function introduced by the
test.

Running in Firebug:

(function(){
var o = { }, lim = 100000,
Object = self.Object,
toString = ({}).toString;

console.time(1);
for (var i=lim; i--; ) Object.prototype.toString.call(o);
console.timeEnd(1);

console.time(2);
for (var i=lim; i--; ) ({}).toString.call(o);
console.timeEnd(2);

console.time(3);
for (var i=lim; i--; ) toString.call(o);
console.timeEnd(3);
})();

1: 28ms
2: 36ms
3: 26ms

Object.prototype.toString.call is faster, and fastest of course is
having no property lookup in the call to |toString|, but that is a
negligible difference and only 2ms a 100k loop.

And of course, as you said, there's a memory consumption overhead, which
should actually directly affect runtime-performance as well. From what
I've seen, every time garbage collector kicks in, there's a runtime
performance hit.


Indeed.

var _toString = ({}).toString;
function foo(o){ return _toString.call(o); }

1 lookup, 1 function call, no object creation at runtime.

Anything done in a loop should be optimized, as should any code that is
called frequently (mousemove, setInterval).

Recursive calls, too, but sometimes a recursive function can be written
clearly using a loop construct, eliminating the extra function calls and
contexts.

Garrett

 

[Garrett Smith]

[...]

Firebug execution is not the same as global execution context.
Performance is affected. Firebug code is interpreted as differently,
too:-

a();
function a(){return 1;}

ReferenceError: a is not defined

Valid program code.

It's not. It appears to be executed as Eval Code

How could that be? eval must parse the string value as a Program. Here's
a perfectly valid program:-

x();
function x(){ console.log('done x!'); }

Maybe it's going line by line.

in a global scope via

`window.eval` with all its consequences (e.g. variable declarations
resulting in properties without DontEnum). It's interesting that
`window.eval` doesn't set `thisArg` to reference `window`, and so `this`
in console references firebug's `_FirebugCommandLine`.

From what I remember `window.eval(/*...*/)` in Gecko is similar to -
`with (window) eval(/*...*/)`. Besides that, Firebug seems to import its
helpers by doing - `with (_FirebugCommandLine) { /*...*/ }`, which would
explain all these slowdowns.

It also leaks some of its housekeeping details:

typeof expr; // "string"

Uh, not good.

I also noticed a |window.f| property doing in the DOM tab.

I have been checking that DOM tab after running my tests and it has
helped me find a couple of undeclared identifiers.

1) run test
2) look at DOM tab
3) check for things like |i|, or other identifiers.

Garrett

 

[abozhilov]

I have another question about delete and internal [[Delete]].

function Foo(){}
Foo.prototype.a = {};

var bar = new Foo();
alert(delete bar.a); //true
alert(bar.a); //[object Object]

1. Assigned to bar reference to object. That object doesn't have `a`
property in object who referred `bar`.
2. Delete `a` property.
3. Get value of `a` property.

In point 2, when be call [[Delete]] internal method of `object` who
`bar` referred. JavaScript will be call [[HasProperty]] method of that
`object`? In this case how JavaScript knows about that property? If
calling [[HasProperty]] he make lookup in prototype chain. In ECMA3 i
see only [[HasProperty]], doesn't exsist internal method who don't
lookup in prototype chain.

Thanks for responses!

 

[abozhilov]

No, [[HasProperty]] is not called. Look at step 5 in 11.4.1; it calls
[[Delete]] of Reference's base object, passing it property name in
question. [[Delete]] then simply returns `true` (step 2 in 8.6.2.5)
since base object (`bar`, not its [[Prototype]]) doesn't have such property.

The usual property lookup (i.e. [[HasProperty]]) is never performed with
`delete`.

Yes, delete isn't call [[HasProperty]] explicit. But when call
[[Delete]] see 8.6.2.5:

1. If O doesn't have a property with name P, return true.

My question is, how JavaScript know for existence on that property?

[[HasProperty]] make lookup in prototype chain.

There's `Object.prototype.hasOwnProperty` infamous for its lack of
support in older (but not ancient) browsers, such as Safari <2.0.4. Also
see <http://pointedears.de/scripts/test/es-matrix/> (can't link to
particular table row there).

Mmm this is interesting. Thank you. But why in specification isn't
have internal method who's works like `hasOwnProperty`? Maybe when
call [[Delete]] JavaScript engine use something like
`hasOwnProperty'.

 

[John G Harris]

I have another question about delete and internal [[Delete]].

function Foo(){}
Foo.prototype.a = {};

var bar = new Foo();
alert(delete bar.a); //true
alert(bar.a); //[object Object]

1. Assigned to bar reference to object. That object doesn't have `a`
property in object who referred `bar`.
2. Delete `a` property.
3. Get value of `a` property.

In point 2, when be call [[Delete]] internal method of `object` who
`bar` referred. JavaScript will be call [[HasProperty]] method of that
`object`? In this case how JavaScript knows about that property? If
calling [[HasProperty]] he make lookup in prototype chain. In ECMA3 i
see only [[HasProperty]], doesn't exsist internal method who don't
lookup in prototype chain.

[[Delete]] and delete both act on the properties of the object, but not
on properties in the prototype chain.

delete returns false if it finds a property with the attribute
DontDelete; in all other cases it returns true, including the case where
there's no such property.

John

 

[Thomas 'PointedEars' Lahn]

There's `Object.prototype.hasOwnProperty` infamous for its lack of
support in older (but not ancient) browsers, such as Safari <2.0.4. Also
see <http://pointedears.de/scripts/test/es-matrix/> (can't link to
particular table row there).

Currently you can link to some rows, but not to this one. You can use

<http://pointedears.de/scripts/test/es-matrix/#o>

though, to make it easier to find it.

I had the same problem several times and have already decided to use more
anchors in the next release. Thanks for mentioning my little project.


PointedEars

 

[abozhilov]

Also note that ES5 spec (currently draft) introduces [[GetOwnProperty]],
and you can see that it is this [[GetOwnProperty]] that's being used in
step 1 of [[Delete]] (see 8.12.7)

Ambiguity begone

That's i want to know. Thanks. With [[GetOwnProperty]] its more
clearly for my.

 

[Thomas 'PointedEars' Lahn]

Np. Is "next release" version available online anywhere?

No, it is not yet publicly available online, that's why I call it a
*release* Meaning that I'm going to *release* it to the public when I
think it is ready (but not necessarily complete). At least I have it in an
SVN repository now, and are filling a PHP array instead of a table, so that
should make things easier (including the changelog); however, there are
still quite a number of entries to be migrated, and code to be written to
accomodate for footnotes and the like (e.g., features being supported in
JScript 5.8 but not in 7.0+ which is likely to cause some gray hair). Rest
assured the announcement of the release will be made here.

While we are at it, because there are quite some differences I'm going to to
list the documented/assumed version, and the earliest tested version for
each feature vertically in the corresponding table cell. Do you (all of
you) think that would be useful or would it rather clutter up the table too
much?

Also, in order to keep the document small, I'm going to enable syntax
highlighting with client-side scripting instead of static `code' elements as
it is now. Are you OK with that? Any suggestions about syntax highlighting
in general?

It would be easier to contribute knowing what changed in new version and
what didn't.

Because of the current lack of a public bug tracking system (I'm getting
ideas here!), just drop me a note (here or via PM) on what you think is
missing/wrong in the current version and I'll consider adding/correcting it
in the next. I don't mind any dupes in the process if you don't mind me
telling you about them

Thank you in advance.


Regards,

 

[Garrett Smith]

Garrett Smith wrote: [...]
The same error is produced if |function a| is interepreted as a
FunctionStatement (Spidermonkey extension). We can test this by
placing |function a| in a block:-

{
a();
function a(){return 1;}
}

ReferenceError: a is not defined

So whatever Firebug is doing with your code, it is not running it as
ProgramCode.

It's not. It appears to be executed as Eval Code

How could that be? eval must parse the string value as a Program.
Here's a perfectly valid program:-

x();
function x(){ console.log('done x!'); }

Maybe it's going line by line.

Maybe. I have no idea (need to look at FB's source).

in a global scope via

Uh, not good.

I also noticed a |window.f| property doing in the DOM tab.

I don't see `window.f` in 1.5X.0a23 (that's one weird version/build
number). Are you sure it wasn't declared by some other script?

Sorry. it's not f, but r, and it explains that a |with| statement is used.

Type into the command line:
console.log(r);
a();
function a(){}

Result:

<div id="_firebugConsole" style="display: none;"
FirebugVersion="1.4.2" firebugCommandLineAttached="true"
methodName="log" expr="with(_FirebugCommandLine){console.log(r); a();
function a(){} };">

So we can see that |a| became a FunctionStatement, and, being a
Statement, is evaluated in the order of Statements.

Now if we run the example in IE, we can see that

Kidding, kidding.

;-D

I have a bookmarklet for that
<http://thinkweb2.com/projects/prototype/detecting-global-variable-leaks/>

Ah, I see now you are talking about the |r| identifier there, too.