What is the scope of this new object ?

[CqN on cr-48]

In the following code:

function t(){

var d = new Date (string)
var t = d.getTime();

....

delete (d); //IS THIS IMPLCITE by the scope rules of js ???
Essentially redundant?
}

 

[Ghasem]

JavaScript has function scope, i.e. variables are accessible inside the function that defines them. So in your code above, variable "d" is accessible only within function "t". The "delete" statement is not needed.

 

[Evertjan.]

Ghasem wrote on 13 aug 2011 in comp.lang.javascript:

JavaScript has function scope, i.e. variables are accessible inside
the function that defines them. So in your code above, variable "d" is
accessible only within function "t". The "delete" statement is not
needed.

"your code above"?

There is on code above!

[please always quote on usenet]

 

[Jukka K. Korpela]

In the following code:

function t(){

var d = new Date (string)
var t = d.getTime();

...

delete (d); //IS THIS IMPLCITE by the scope rules of js ???
Essentially redundant?
}

It is a no-operation, and raises a SyntaxError exception in strict mode.
(On Firefox in non-strict mode, it causes a warning.

The delete operator deletes a property of an object. When the operand is
an unqualified variable, as here, it has no effect.

Now, to answer the completely different question you asked in the
Subject line, the answer is that objects do not have scopes. After the
assignment where you create an object, a reference to the object might
be assigned to other variables, like global variables, keeping the
object accessible until the execution of the program. But if such
assignments are not made, the object effectively ceases to exist (and it
may be gargage collected) when the only reference to it vanishes because
it was in a variable local to a function and the function was exited.

 

[Lasse Reichstein Nielsen]

In the following code:

function t(){

var d = new Date (string)
var t = d.getTime();

...

delete (d); //IS THIS IMPLCITE by the scope rules of js ???

That depends on what you expect it to do.
It actually does nothing in this case (if you check, it evaluates to false,
which represents the delete failing).
The "delete" operator in Javascript deletes bindings, not objects. You are
trying to delete the "d" variable itself, not the Date object that it refers
to, but variables declared using "var" can't be deleted so nothing happens.

Essentially redundant?

Fundamentally a no-op, so definitly redundant.

If you want to delete the Date object, all you need to do is to stop
having a reference to it. In this case, the only reference to the Date
object is the "d" variable, and it will stop existing when the function
call that declared it ends. I.e., when the function returns, the Date
object is no longer available, and it will eventually be garbage collected.

If you wanted the Date object to be garbage collectable earlier than
that (more likely in a case where you have a variable referencing a
much larger object, and you are doing a lot of work before returning
from the function), you can overwrite the reference by assigning a new
value to "d", e.g., "d = null;". If d held the only reference to the
object, then the object can no longer be accessed after the assignment,
and the garbag collector may collect it at will.

In this sense, JavaScript is a arbage collected language like Java,
which also has "new", but not "delete".

/L

 

[Thomas 'PointedEars' Lahn]

It is a no-operation,

No, it is not.

and raises a SyntaxError exception in strict mode.

Which is additional proof that it is _not_ a no-operation.

(On Firefox in non-strict mode, it causes a warning.

_In JavaScript_, not "on Firefox".

The delete operator deletes a property of an object. When the operand is
an unqualified variable, as here, it has no effect.

(What do you consider to be a qualified variable, then?)

The `delete' operator deletes properties of native objects that do not have
the `[[DontDelete]]' attribute (in ES5, properties that do have the
[[Configurable]] attribute). Identifiers that are declared as variables are
properties of the Variable Object of the execution context they are declard
in and have the `DontDelete' attribute (in ES5, they are References to an
Environment Record binding, respectively).

In addition, in ECMAScript Ed. 5 strict mode an expression cannot be operand
to the `delete' operator if its value "is a direct reference to a variable,
function argument, or function name(11.4.1)" [ES5, Annex C], which follows
from that being "a Reference to an Environment Record binding" there.

*Therefore*, and not for other reasons, the `delete' operation *fails* here.
It is _not_ a no-operation.


PointedEars

 

[Lasse Reichstein Nielsen]

No, it is not.

In this case, it is. The state before and after is the same.
Obviosuly, that's assuming that the code isn't strict-mode code.
I think that's a safe assumption in this case.

Which is additional proof that it is _not_ a no-operation.

If "it" refers to the delete operator in general, agree.
If "it" refers to the actual use above, disagree.

_In JavaScript_, not "on Firefox".

Why not "on Firefox" (ok, "in Firefox" would be better, but let's not
be pedantic[1]).

It is Firefox that decides to show a warning in the console.
The Mozilla JavaScript specification has no notion of warnings. See, e.g.,
https://developer.mozilla.org/en/JavaScript/Reference/Operators/Special/delete
It's quite possible to have a JavaScript implementation that doesn't
show a warning.

The delete operator deletes a property of an object. When the operand is
an unqualified variable, as here, it has no effect.

(What do you consider to be a qualified variable, then?)

The `delete' operator deletes properties of native objects that do not have
the `[[DontDelete]]' attribute (in ES5, properties that do have the
[[Configurable]] attribute). Identifiers that are declared as variables are
properties of the Variable Object of the execution context they are declard
in and have the `DontDelete' attribute (in ES5, they are References to an
Environment Record binding, respectively).

... unless the variable was declared in eval code, in which case it can
be deleted.

[strict mode is different]

*Therefore*, and not for other reasons, the `delete' operation *fails* here.

It is _not_ a no-operation.

The delete operator in general, no. In this case, yes.
It does return false, but the result is ignored, so an optimizing compiler
could get away with generating absolutely no code for the statement.
That's a pretty good sign of being a no-op.

/L
[1] A-ha-ha-haaa. Right. Good one.

 

[Thomas 'PointedEars' Lahn]

In this case, it is. The state before and after is the same.

That is not the definition of a no-operation.

Obviosuly, that's assuming that the code isn't strict-mode code.

A `delete' operation checks its operand and can throw an exception even when
not in strict mode. A no-operation on the other hand does nothing at all.

If "it" refers to the delete operator in general, agree.
If "it" refers to the actual use above, disagree.

Your problem. It takes a non-zero number of steps for the `delete'
operation here. If it was a no-operation, the number of steps were zero.

_In JavaScript_, not "on Firefox".

Why not "on Firefox" (ok, "in Firefox" would be better, but let's not
be pedantic[1]).

It is Firefox that decides to show a warning in the console.
The Mozilla JavaScript specification has no notion of warnings.

There is no "Mozilla JavaScript specification" – you made that up. Warnings
are a feature of the SpiderMonkey JavaScript script engine embedded in e.g.
Firefox (and compatible implementations, like Rhino and Narcissus); the
error console of Firefox (among other Firefox extensions, like Firebug, and
Mozilla-based browsers) only employs them.

See, e.g.,
https://developer.mozilla.org/en/JavaScript/Reference/Operators/Special/delete
It's quite possible to have a JavaScript implementation that doesn't
show a warning.

You are confusing browsers with ECMAScript implementations, JavaScript with
ECMAScript, and JavaScript with other ECMAScript implementations.

The delete operator deletes a property of an object. When the operand is
an unqualified variable, as here, it has no effect.

(What do you consider to be a qualified variable, then?)

The `delete' operator deletes properties of native objects that do not
have the `[[DontDelete]]' attribute (in ES5, properties that do have the
[[Configurable]] attribute). Identifiers that are declared as variables
[[are properties of the Variable Object of the execution context they are
declard in and have the `DontDelete' attribute (in ES5, they are
References to an Environment Record binding, respectively).

.. unless the variable was declared in eval code, in which case it can
be deleted.

Unless the eval code is strict code in which case there is nothing to
delete, but the `delete' operation does not throw an exception and it
evaluates to `true'. Which might be a Chromium 13.0.782.107 V8 (presumably
3.3.10.17) bug; but I am not sure if I understand ES5, section 11.4.1, steps
2 and 3 correctly.

Source code:

eval("'use strict'; var x = 42;");

/* throws ReferenceError when uncommented */
// x;

/* true in said Chromium version, no SyntaxError */
delete x;

/* throws ReferenceError */
x;


PointedEars