The "undefined" value

[Luke Matuszewski]

Richard Cornford has wrote great part of what i expected.

PS to avoid errors in statemtens like alert(cool) we could use
alert(this.cool); /* and thus really using [[Get]] method of JavaScript
which returns undefined if cool is not in scope */

Best regards.
Luke.

 

[Martin Honnen]

So, if you specify LANGUAGE="JavaScript1.2" you may get two different
sorts of language behaviour from the interpreter depending on which
browser is used. This is a _bad_thing_.

Note <https://bugzilla.mozilla.org/show_bug.cgi?id=255895>, with Firefox
1.5 (already in the betas and release candidates) Mozilla has dropped
the change that <script language="JavaScript1.2"> used to trigger for
script evaluation.
Of course one more reason not to use <script language="JavaScript1.2">
in HTML documents these days.

 

[John G Harris]

This situation was fully satisfying for everyone except some bored
academical minds. These minds did not like the fact that there is
something that has a string representation ("undefined") but is not
represented per se.

Thus they have introduced *undefined* value. The consequence they did
not think about was that this value will be able by default participate
in the comparison operations *and* in the assignment operations. This
created the following definitely buggy situation:

<snip>

No. In old browsers, ECMA 262 v2, the complicated rules for == meant you
couldn't tell the difference between null and undefined (never assigned
to).

Newer browsers, as recorded in ECMA 262 v3, have === which does allow
you to tell the difference. If x has never been assigned to it must now
have something it is === to, and it can't be null so they invented a new
keyword, undefined, to be that something.

John

 

[Randy Webb]

Richard Cornford said the following on 11/20/2005 9:19 AM:

Randy Webb wrote:



You don't think that Lasse Reichstein Nielsen has a better claim on that
title (for his ability to place the theory in a wider context than I
can)?

Never really thought about that one. I do know that when it comes to the
specs, I have never seen him be wrong about what they say.

::Off to ponder Lasse being a Theorist::
<g>

 

[Randy Webb]

Lasse Reichstein Nielsen said the following on 11/20/2005 7:44 AM:

Well, that would be a different interpretation of "ECMA 262 compliant"
than it uses itself. ECMAScript is meant to be extended, both at the
runtime environment level with host objects, and with extended syntax
and semantics. Being compliant means following everthing in the standard,
but there is no requirement of "nothing more".

Fair enough.

That said, I doubt there will ever be a 100% compliant implementation
anyway. There will probably always be some obscure corner case that
is implemented slightly incorrectly when used on the first Thursday
of a month. "The number of bugs in a program is constant over time."

Indeed

Indeed. Still, the major problem with scripting browsers is not the
Javascript language, browsers are very close to ECMAScript compliance.
It is the browser DOM, which differs widely.

100% Agreed.

 

[Lasse Reichstein Nielsen]

The original question was if those constructs were legit. Is it a
"standard" to use the "Javascript1.2" construct or not.

It is "standard" in the sense that it *can* be used in a validating
HTML 4.01 Transitional document.
The behavior is *not* standardized, but left up to the clients that
uses it.
It was never recommended by the W3C. The "language" attribute was
deprecated already in the first version of HTML that included it.
It was only included for compatability with existing browsers and
pages.

The use of "JavaScript1.2" as the version is possibly the worst value
of the language attribute that one can use, since it specifies a
version of Javascript that differs from other versions on the *same*
syntax. If it matters for your page, then the page *will* break in
the browsers that only support one version of Javascript.

/L

 

[Thomas 'PointedEars' Lahn]

Richard Cornford has wrote great part of what i expected.

What are you referring to?

PS to avoid errors in statemtens like alert(cool) we could use
alert(this.cool); /* and thus really using [[Get]] method of
JavaScript which returns undefined if cool is not in scope */

True. However, `this.cool' is not always the same as `cool':

var cool = 42;

function Foo()
{
alert([this.cool, cool])
}

Foo.prototype = {
Foo: Foo,
cool: 1337
};

Foo(); // 42,42
var foo = new Foo(); // 1337,42
foo.Foo(); // 1337,42


PointedEars

 

[Dr John Stockton]

JRS: In article <[email protected]>
, dated Sun, 20 Nov 2005 08:30:00, seen in

( * so there is no programmical way to test if variable was defined but
not assigned a value explicitly... but i assume there is no need to )

var U // DO NOT ASSIGN TO U
var X
var Z1 = X==U
X = "something"
var Z2 = X==U
X = U
var Z3 = X==U
alert([Z1, Z2, Z3])

gives true,false,true so that one can very nearly tell.

Consider

function Inc(Parameter, maybeAnother) { var R, U
R = Parameter
if (maybeAnother != U) R += maybeAnother
return R }

(modelled on something in another language) which indicates a possible
use of testing for undefined.

The introduction of undefined as a keyword meaning undefined was a
great mistake, no doubt originated by a person with inadequate
experience of linguistics -- it makes discussion of the subject
unnecessarily difficult. Something like undef would have been
better, or unbestimmt or something neologistic such as wotzat .

There's something for saying that a language should not have reserved
words; instead, it should have reserved not-words - for example,
funkshun rather than function .

Implementations of Algol often used one of [ ' " ] as string quote and
the other as reserved word quote; and I recall one where "begin" was
written !begin but could be written as !beg. instead - any
special word could be so abbreviated to the minimum needed to be
differentiated from others. It made various forms of processing,
including discussion, easier. part of the software would expand any
such abbreviations.

 

[Lasse Reichstein Nielsen]

( * so there is no programmical way to test if variable was defined but
not assigned a value explicitly... but i assume there is no need to )

There shouldn't be a way, because there is no difference between a
declared variable that has not been assigned to, and one that has been
assigned the undefined value.

When you declare a variable, you create a property on the variable
object (the global object if in global scope). Quoting section 12.2
of ECMA262 3rd ed.:
"Variables are initialised to undefined when created."


(Curiosity: variable properties are created with the property attribute
DontDelete, except when inside eval scope. The following alerts the
result "number, undefined":
(function() {
var x = 42;
eval("var y = 37;");
delete x;
delete y;
alert([typeof x, typeof y]);
})()
The wonders of reading ECMA262 ...

/L