Primitive Re-definition

[Jeremy J Starcher]

var TRUE = true,
FALSE = false,
undefined = undefined;

I've also seen something similar in the jQuery source code.

In 9 years of JavaScript development, I've never seen such a thing done.
Am I right to think that this pattern is practically pointless in most
if not all cases, or did I miss the boat on this one?

The original versions of Javascript did not have an 'undefined' constant,
though they did have an undefined value.

For a while, it was common to include the line:
var undefined;

in your script.

Hasn't been needed in ... a long while now.

 

[Thomas 'PointedEars' Lahn]

The original versions of Javascript did not have an 'undefined' constant,
though they did have an undefined value.

What are you talking about? The very problem and the cause of this thread
is that `undefined' is _not_ a constant; it is a property of the global
object, if that, that can successfully be assigned to.

For a while, it was common to include the line:
var undefined;

in your script.

Apparently you have not been paying attention.

If that was so, it was as error-prone as it is now, at least in the global
execution context. Because variable instantiation happens before execution,
and variable redeclaration does _not_ reset an existing properties'/already
declared variable's value. Suppose the global object has a property named
`undefined', as in implementations of ECMAScript Edition 3 Final, then

/* injected by foreign script */
undefined = true;

/* in one's own script */
var undefined;

does not change anything.

Hasn't been needed in ... a long while now.

Because of the variability of `undefined', it may appear to be necessary to
define one's own in one's scripts.

Please leave one attribution line per quotation level.


PointedEars

 

[Jeremy J Starcher]

What are you talking about? The very problem and the cause of this
thread is that `undefined' is _not_ a constant; it is a property of the
global object, if that, that can successfully be assigned to.

Poor choice of words. The early implementations did not have a property
of the global object with the name 'undefined.'

For a while, it was common to include the line: var undefined;

in your script.

Apparently you have not been paying attention.

If that was so, it was as error-prone as it is now, at least in the
global execution context. Because variable instantiation happens before
execution, and variable redeclaration does _not_ reset an existing
properties'/already declared variable's value. Suppose the global
object has a property named `undefined', as in implementations of
ECMAScript Edition 3 Final, then [snip]

I'm not saying it wasn't error prone. I am saying that if you wanted a
variable or property with the value of undefined to check against, you
had to create your own and 'undefined' was the popular choice.

ECMAScript Edition 3 Final means nothing in this context, because this
practice (and its need) are much earlier than this standard. I believe
that good coders should have a sense of history, not only about computers
in general, but about the language they are using. I bring this up out
of that sense of history.n

 

[Garrett Smith]

On Sep 14, 5:24 am, Thomas 'PointedEars' Lahn <[email protected]>
wrote:
[...]

However, identifying `window' with `this' (i.e., the reference
to the ECMAScript Global Object here) is jQuery's first bug, of course.

I understand that `window' is a property of the Global Object. But
besides semantics, what else could that misconception cause?

Semantics *is* the problem. One object is a host object; the other one is
not. One object has built-in properties that have a special meaning; the
other one doesn't have them, and vice-versa.

In a recent thread "Re: [[Delete]]'ing window properties in IE", we
discussed how IE's global object also a host object, and it is not the
global variable object.

| The global variable object is implemented as a JScript object, and the
| global object is implemented by the host.

Taken from Eric Lippert's blog entry.

 

[jdalton]

Hi All,

Just wanted to give a heads up to those performing benchmarks and
tests on local vs global lookup speeds.
It has been done before in the clj. Here are some more benchmarks
(which link to the clj threads)

http://homepage.mac.com/jorgechamorro/cljs/032/
http://homepage.mac.com/jorgechamorro/cljs/033/

- JDD

 

[Garrett Smith]

On Sep 14, 3:17 pm, Lasse Reichstein Nielsen <[email protected]>
wrote: [...]
These do make some sense. Avoiding lookups on the global object does
make a difference (but as with all optimizations - don't do it unless
you have profiled and found it to make a signficant contribution).
Your hint about the length of the scope chain got me thinking about
making it longer - so I did. However, avoiding global lookups still
doesn't make a lot of difference. I also made the comparison in the
same scope as the function running the loop so that only the undefined
lookup should use the scope chain.

IE:
Global undefined level 0: 172
Global undefined level 1: 234
Global undefined level 2: 281
Local level 0: 47
Local level 2: 156

Firefox:
Global undefined level 0: 2
Global undefined level 1: 153
Global undefined level 2: 151
Local level 0: 2
Local level 2: 124

Performance seems to be enhanced more by executing statements as
global code than messing with local declarations of global variables.

I looked at the code again and realised the counter i was still being
looked-up along the scope chain, so I created a local alais. Here's
the new results:

IE
Global undefined level 0: 172
Global undefined level 1: 156
Global undefined level 2: 188
Local level 0: 62
Local level 2: 63

Firefox
Global undefined level 0: 1
Global undefined level 1: 2
Global undefined level 2: 1
Local level 0: 1
Local level 2: 1

So it would seem that global properties like undefined may well
already be optimised and that creating a local scope for such
variables has no measurable performance benefit.

Let me guess, was it FF3.5.x you were testing with?

The thing is that newer engines (especially FF3.5 which, afaik, should
have JIT on) are rather indifferent to these optimizations.

The release notes for TraceMonkey, Mozilla's new javascript engine, do
not mention that[1], but I think if TraceMonkey is not doing that, it
would be possible.

I believe TraceVis would tell you. I'm not yet running that so I can't
say I know for sure.

There may be a potential optimization for removal of unused identifiers
in closures.

If an identifier is declared in the enclosing scope of a group of
functions, and a lexical scan of those nested functions, e.g. "look into
scope" reveals that none of those nested functions access that
identifier, do not make use of |eval| and the enclosing scope does not
use |eval| or assign to |arguments| properties and no nested scopes
access their respective |arguments|, can optimizing JS interpreter
collect them as garbage? I feel like I am missing some cases related to
|with| but can't think of them off the top of my head.

Is this possible?

This another one of those "if a tree falls in the forest, does it make a
sound?"

[1]http://hacks.mozilla.org/2009/07/tracemonkey-overview/

 

[Garrett Smith]

Jeremy J Starcher wrote:

[...]

For a while, it was common to include the line: var undefined;

in your script.

Apparently you have not been paying attention.

If that was so, it was as error-prone as it is now, at least in the
global execution context. Because variable instantiation happens before
execution, and variable redeclaration does _not_ reset an existing
properties'/already declared variable's value. Suppose the global
object has a property named `undefined', as in implementations of
ECMAScript Edition 3 Final, then [snip]

I'm not saying it wasn't error prone. I am saying that if you wanted a
variable or property with the value of undefined to check against, you
had to create your own and 'undefined' was the popular choice.

Yep, and now you don't need to do that anymore, but if you do it won't
cause any problems. If you do it in a closure, the side effects would be
smaller file size and shorter scope chain to resolve the identifier.
Doesn't sound all that bad, does it?

 

[Thomas 'PointedEars' Lahn]

On Sep 14, 5:24 am, Thomas 'PointedEars' Lahn <[email protected]>
wrote:
[...]
However, identifying `window' with `this' (i.e., the reference
to the ECMAScript Global Object here) is jQuery's first bug, of course.
I understand that `window' is a property of the Global Object. But
besides semantics, what else could that misconception cause?

Semantics *is* the problem. One object is a host object; the other one is
not. One object has built-in properties that have a special meaning; the
other one doesn't have them, and vice-versa.

In a recent thread "Re: [[Delete]]'ing window properties in IE", we
discussed how IE's global object also a host object, and it is not the
global variable object.

| The global variable object is implemented as a JScript object, and the
| global object is implemented by the host.

Taken from Eric Lippert's blog entry.

Your point being?


PointedEars