The "undefined" value

[matty]

Hi,

I recently got very confused (well that's my life) about the
"undefined" value. I looked in the FAQ and didn't see anything about
it. On http://www.webreference.com/programming/javascript/gr/column9/
they say:

<snip>
The undefined property
A relatively recent addition to JavaScript is the undefined property.
It's useful when you want to test whether a variable has been
initialized or not.

var a;

if ( a == undefined ) a = "some value";
</snip>

Is this really valid? Shouldn't it be "if (typeof a == 'undefined') ?

Would an explanation on what "undefined" is and how to check for it be
a good entry for the FAQ?

Thanks,

Matty.

 

[Luke Matuszewski]

In ECMAScript 3rd specs the word 'undefinde' occurs on
4.2 Language Overview
<quote>
Properties are containers that hold
other objects, primitive values, or methods. A primitive value is a
member of one of the following built-in
types: Undefined, Null, Boolean, Number, and String; an object is a
member of the remaining built-in
type Object; and a method is a function associated with an object via a
property.
</quote>

In 4.3.9 Undefined Value we can read:
<quote>
The undefined value is a primitive value used when a variable has not
been assigned a value.
</quote>
and then in 4.3.10 Undefined Type we see:
<quote>
The type Undefined has exactly one value, called undefined.
</quote>

, where word 'undefined' is bolded... so it is a part of spec... thus
yes: 'undefinded' is a value
(we can eg. read also in 10.1.3 Variable Instantiation that
<quote>
On entering an execution context, the
properties are bound to the variable object in the following
order...)
If
the caller supplies fewer parameter values than there are formal
parameters, the extra formal
parameters have value undefined. If two or more formal parameters share
the same name, hence the
same property, the corresponding property is given the value that was
supplied for the last parameter
with this name. If the value of this last parameter was not supplied by
the caller, the value of the
corresponding property is undefined.
</quote>

This 'undefined' is a value from JavaScript 1.3 (and we remember that
JavaScript 1.3 was comformant to ECMAScript 1rd release).
So primitive values can be used directly, this includes:
- undefined
- null
- any string
- any number (which is double-precision 64-bit format IEEE 754);
- true
- false (which are booleans);
(of course there are also literals, and in literals we have Integer
Literals and so on).

typeof can be used, but you must remember the 'bugs' that it has:
typeof(null) == "object"
typeof(new Array) == "object"
typeof(undefinded) == "undefinded"
var myVar;
typeof(myVar) == "undefined"
var myVar1 = 1;
typeof(myVar1) == "number"
typeof("mystr") == "string" or typeof "mystr" == "string"
typeof true = "true"
typeof false = "false"

and so on...
Best regards.

 

[Thomas 'PointedEars' Lahn]

<snip>
The undefined property
A relatively recent addition to JavaScript is the undefined property.
It's useful when you want to test whether a variable has been
initialized or not.

var a;

if ( a == undefined ) a = "some value";

That statement is false, even for ridiculous high values for time passed
from the moment till now for still being "recent". Most notably, one
can easily assign the `undefined' value (the sole value of the built-in
Undefined type), or some other false-values for that matter, to a variable
and property and the conditional expression would still evaluate to `true'.

var a;

// either will apply here
a = void 0; // applies because the `void' operator evaluates to the
// `undefined' value the `undefined' property refers to
a = this.bla; // provided this.bla was not defined
a = null; // applies due to implicit type conversion

// either will not apply here
a = false;
a = 0;
a = NaN;

if (a == undefined) // provided the `undefined' property is supported
{
alert("undefined?");
}
else
{
alert("defined?");
}

if (b == undefined) // breaks, since b was not declared and not defined
{
// ...
}

var b; // applies to the below condition

if (typeof b == "undefined") // almost never breaks if b was declared
or defined, see below
{
alert("undefined?")
}

</snip>

Is this really valid?

Depends on what you call "valid". It is syntactically correct ECMAScript
compliant code. It should not error in JavaScript 1.3+ (NN 4.06+ [1998])
and JScript 5.5+ (IE/Win 5.5+ [?]), provided that `a' was either declared
or defined before. The condition in the sentence before clearly indicates
that the approach cannot serve as suitable test of what it is explained
above to be.

Shouldn't it be "if (typeof a == 'undefined') ?

That is the approach used to ensure the script does not break in most
script engines and, in contrast to the first approach, does not break
with non-instantiated local properties (such as undeclared and not defined
variables). This (the `typeof' operator) is supported since ECMAScript 1,
JavaScript 1.1 (NN3+ [Aug. 1996]) and JScript 1.0 (IE/Win 3.0+ [?]).
However, as I wrote before, `undefined' is _not_ "not defined".
It is a special value.

If I should put it bluntly: you should delete all references to that
Web site you quoted from. The information there is not only outdated,
it is utterly wrong.

Would an explanation on what "undefined" is and how to check for
it be a good entry for the FAQ?

I do not think so as I do not perceive it as a frequently asked
question here and anyone who can read and understand the references
and specifications pointed to in the FAQ knows the (low) level of
support for it compared to `typeof ... == "undefined"'.


PointedEars

 

[matty]

typeof can be used, but you must remember the 'bugs' that it has:
typeof(null) == "object"
typeof(new Array) == "object"
typeof(undefinded) == "undefinded"
var myVar;
typeof(myVar) == "undefined"
var myVar1 = 1;
typeof(myVar1) == "number"
typeof("mystr") == "string" or typeof "mystr" == "string"
typeof true = "true"
typeof false = "false"

Thank you. But what bugs?
Matty.

 

[Luke Matuszewski]

Thank you. But what bugs?
Matty.

Main bug was that:
typeof(null) == "object"
, since null is primitive value and not an object. The same for Array
so:
typeof(new Array) == "object"
which is returned as "object", but Array is special kind of it
(especially it has a lenght property which specifies numer of its
elements).

 

[Thomas 'PointedEars' Lahn]

In ECMAScript 3rd specs the word 'undefinde' occurs on

He was talking support for the the `undefined' property
which represents the internal `undefined' value.

This 'undefined' is a value from JavaScript 1.3
True.

(and we remember that JavaScript 1.3 was comformant to ECMAScript 1rd
release).

False.

,-<URL:http://research.nihonsoft.org/javascript/ClientGuideJS13/intro.html#1013678>
|
| JavaScript 1.1 ECMA-262 is based on JavaScript 1.1.

That is a completely different thing, as tests have shown.

typeof can be used, but you must remember the 'bugs' that it has:
typeof(null) == "object"

`null' is the sole value of the `Null' type, a type for object
references. It "is a primitive value that represents the null,
empty, or non-existent reference." (ECMAScript 3 Final, 4.3.11)
It is perfectly understandable that "object" is yielded.

`typeof' is not a function but an operator. Given whitespace
(even newline) between operator and operand, no parentheses are
necessary.

typeof(new Array) == "object"

Array objects are objects, as are other core objects. No surprise here.

typeof(undefinded) == "undefinded"

There is no built-in `undefinded' property or variable and no conforming
ECMAScript implementation that evaluates a TypeofExpression to
"undefinded" (except for host objects). You probably meant

typeof undefined == "undefined"

Since that is the specified behavior, there is no bug whatsoever.

var myVar;
typeof(myVar) == "undefined"

Declared, but not initialized variables are assigned the `undefined' value.
No surprise here

var myVar1 = 1;
typeof(myVar1) == "number"

or here

typeof("mystr") == "string" or typeof "mystr" == "string"

or here.

typeof true = "true"
typeof false = "false"

Provided that you did not mean an AssignmentExpression, there is no
ECMAScript compliant implementation that evaluates either left-hand
side expression to "true" or "false". A conforming implementation
evaluates both of them to "boolean". I wonder what implementation
you have tested with; probably none.


PointedEars

 

[Thomas 'PointedEars' Lahn]

Main bug was that:
typeof(null) == "object"
, since null is primitive value and not an object.

That is not a bug.

The same for Array
so:
typeof(new Array) == "object"
which is returned as "object", but Array is special kind of it
(especially it has a lenght property which specifies numer of its
elements).

That Array objects are considered objects because they are ("a
special kind of") object is a bug? You are not making any sense.


PointedEars

 

[matty]

var a;

// either will apply here
a = void 0; // applies because the `void' operator evaluates to the
// `undefined' value the `undefined' property refers to
a = this.bla; // provided this.bla was not defined
a = null; // applies due to implicit type conversion

// either will not apply here
a = false;
a = 0;
a = NaN;

if (a == undefined) // provided the `undefined' property is supported
{
alert("undefined?");
}
else
{
alert("defined?");
}

if (b == undefined) // breaks, since b was not declared and not defined
{
// ...
}

var b; // applies to the below condition

if (typeof b == "undefined") // almost never breaks if b was declared
or defined, see below
{
alert("undefined?")
}

Thank you that was a very good explanation. My confusion was not
realizing that there is an undefined value AND an "undefined" type, as
Luke mentionned, and that an undeclared variable is not undefined, it
simply doesn't exist.

If I should put it bluntly:

LOL do you really have to ask.

you should delete all references to that

Web site you quoted from. The information there is not only outdated,
it is utterly wrong.

I cannot possibly delete references from all websites that contain
wrong information. On the contrary I think it is beneficial to others
to keep the reference so that they know they cannot trust it as you
properly demonstrated.

I do not think so as I do not perceive it as a frequently asked
question here and anyone who can read and understand the references
and specifications pointed to in the FAQ knows the (low) level of
support for it compared to `typeof ... == "undefined"'.

Sigh. [psf 10.1]

Why did I even ask LOL. Your perception is yours. You may think that my
original question is extremely basic, and that I shouldn't even have
posted it because I should know better. I _personally_ think that the
confusion is legitimate and it doesn't hurt going in detail like you
did to make things clearer for everyone. There are topics in the FAQ
that I _personally_ perceive as not "frequently asked" (e.g. 4.11) and
some others like 4.19 that I _personally_ believe everyone should know,
had they "read and understood the references and the specifications".
It was just a suggestion, and given the excellent examples given in the
replies, I _personally_ believed they would be a good reference in the
FAQ, since I couldn't find them anywhere else and the only thing I
found was <quote>utterly wrong</quote> (which I now agree with).

Matty

 

[Luke Matuszewski]

False.

,-<URL:http://research.nihonsoft.org/javascript/ClientGuideJS13/intro.html#1013678>
|
| JavaScript 1.1 ECMA-262 is based on JavaScript 1.1.

That is a completely different thing, as tests have shown.

Generally you are right, but i think i mentioned JavaScript 1.3 because
JavaScript 1.2 had a terrible bug in operators == and != which
performed strict equality/inequality. JavaScript 1.3 defined new
operators for such strict equality === and !==.
In JavaScript 1.1 == and != operators wasn't performing this strictness
thing like in JavaScript 1.2.

`null' is the sole value of the `Null' type, a type for object
references. It "is a primitive value that represents the null,
empty, or non-existent reference." (ECMAScript 3 Final, 4.3.11)
It is perfectly understandable that "object" is yielded.

I think this is a matter of deduction... from my point of view all
primitive values are NOT objects so they should evaluate by typeof to
propert strings such as
var a, b = null;
if(typeof b == "null") {
/* */
}

`typeof' is not a function but an operator.

Yes, you are correct.

Provided that you did not mean an AssignmentExpression,

Yes, you are right - i forgot/omitted the remaining =

ECMAScript compliant implementation that evaluates either left-hand
side expression to "true" or "false". A conforming implementation
evaluates both of them to "boolean". I wonder what implementation
you have tested with; probably none.

And again you are right here.

Thanks and best regards.
Luke.

 

[Thomas 'PointedEars' Lahn]

[...] i mentioned JavaScript 1.3 because JavaScript 1.2 had a terrible bug
in operators == and != which performed strict equality/inequality.
JavaScript 1.3 defined new operators for such strict equality === and !==.
In JavaScript 1.1 == and != operators wasn't performing this strictness
thing like in JavaScript 1.2.

Unfortunately I cannot install a JavaScript 1.2-only UA (NN 3) here
to check this.

[snipped because of ACK]

Please include an empty line between quote and new text, prose and source
code, and in your new text now and then, to ease reading. And please do
not remove attributions for still _quoted_ text completely.


Regards,
PointedEars

 

[Matt Kruse]

Generally you are right, but i think i mentioned JavaScript 1.3
because JavaScript 1.2 had a terrible bug in operators == and != which
performed strict equality/inequality.

I don't remember the facts exactly and I don't have time to look it up right
now...

But I thought that there was some confusion about this functionality when
1.2 was coming out. Originally, they decided that == and != should behave
like === and !==. Netscape 4 was released during this time, and since it
wasn't finalized, they decided to only implement this functionality inside
of <script language="Javascript1.2"> tags. After the release, the decision
was reversed so that == and != did _not_ function like the current === and
!==, so the only situation affected was NN4 inside of <script
language="Javascript1.2"> tags.

I may remember wrong, though. Please correct me if so

 

[Thomas 'PointedEars' Lahn]

False.

,-<URL:http://research.nihonsoft.org/javascript/ClientGuideJS13/intro.html#1013678>
|
| JavaScript 1.1 ECMA-262 is based on JavaScript 1.1. ^^^
That is a completely different thing, as tests have shown.

Generally you are right, [...]

I'm sorry, somehow I read "1.3" where there was "1.1" and vice-versa.

,-<URL:http://research.nihonsoft.org/javascript/ClientGuideJS13/intro.html#1013678>
|
| JavaScript 1.3 | JavaScript 1.3 is fully compatible with ECMA-262. [...]

I'd say that confirms your statement. My bad.


PointedEars

 

[Luke Matuszewski]

Matt Kruse napisal(a):

After the release, the decision
was reversed so that == and != did _not_ function like the current === and
!==, so the only situation affected was NN4 inside of <script
language="Javascript1.2"> tags.

I may remember wrong, though. Please correct me if so

You are right. It is even mentioned on page with Rhino implementation.
Here is a link:
http://www.mozilla.org/rhino/overview.html - go to the "JavaScript
Language Versions" paragraph.

Best regards.
Luke.

 

[matty]

Matt Kruse napisal(a):

You are right. It is even mentioned on page with Rhino implementation.
Here is a link:
http://www.mozilla.org/rhino/overview.html - go to the "JavaScript
Language Versions" paragraph.

Best regards.
Luke.

Ha! I couldn't remember where I saw an official (official is to be
debated, I know) website tell me that I had to use
"language='Javascript1.2" and that's where it was !

So what's the deal? From what I understand we should use
"type=text/javascript" and not the "language=...". Is there a clear
explanation on an official website (i.e. not related to a particular
product) that tells me what to do with this ?

Matty

 

[Thomas 'PointedEars' Lahn]

http://www.mozilla.org/rhino/overview.html - go to the "JavaScript
Language Versions" paragraph.
[...]

Ha! I couldn't remember where I saw an official (official
is to be debated, I know) website tell me that I had to use
"language='Javascript1.2"

The document referred to does not tell you this.

and that's where it was !

So what's the deal? From what I understand we should use
"type=text/javascript" and not the "language=...". Is there a clear
explanation on an official website (i.e. not related to a particular
product) that tells me what to do with this ?

They already are (implicitly) telling you _not_ to use it.


PointedEars

 

[matty]

http://www.mozilla.org/rhino/overview.html - go to the "JavaScript
Language Versions" paragraph.
[...]

Ha! I couldn't remember where I saw an official (official
is to be debated, I know) website tell me that I had to use
"language='Javascript1.2"

The document referred to does not tell you this.

and that's where it was !

So what's the deal? From what I understand we should use
"type=text/javascript" and not the "language=...". Is there a clear
explanation on an official website (i.e. not related to a particular
product) that tells me what to do with this ?

They already are (implicitly) telling you _not_ to use it.

I must be a complete moron but when I read:

<quote>
Some behavior in the JavaScript engine is dependent on the language
version. In browser embeddings, this language version is selected using
the LANGUAGE attribute of the SCRIPT tag with values such as
"JavaScript1.2".
</quote>

Then I understand "to use this particular engine you must specify
"Javascript1.2" in the script tag"

It's okay to tell me that i'm a complete moron.

Matty.

 

[Randy Webb]

Thomas 'PointedEars' Lahn said the following on 11/20/2005 12:11 AM:

matty wrote:

http://www.mozilla.org/rhino/overview.html - go to the "JavaScript
Language Versions" paragraph.
[...]

Ha! I couldn't remember where I saw an official (official
is to be debated, I know) website tell me that I had to use
"language='Javascript1.2"

The document referred to does not tell you this.

It does, just not directly.

They already are (implicitly) telling you _not_ to use it.

Nonsense. Whether you use it or not depends on the behavior you want.
But to be in a position to decide the answer to that question, you have
to understand the consequences of that action and if you truly
understand the consequences, then the question becomes moot.

 

[Randy Webb]

matty said the following on 11/20/2005 12:33 AM:

Thomas 'PointedEars' Lahn wrote:



I must be a complete moron but when I read:

You are not the moron.

<quote>
Some behavior in the JavaScript engine is dependent on the language
version. In browser embeddings, this language version is selected using
the LANGUAGE attribute of the SCRIPT tag with values such as
"JavaScript1.2".
</quote>

Then I understand "to use this particular engine you must specify
"Javascript1.2" in the script tag"

And whether you use that language attribute or not will be dependent on
what behavior you are looking for. But to understand that behavior, and
whether you want it or not, you have to understand the behaviors
themselves. And once you understand them, the question becomes moot.

The W3C tells you to use the type attribute (but I have never cared what
W3C or ECMA say), but use the type attribute because it removes the
language attribute differences/behaviors from certain browsers.

It's okay to tell me that i'm a complete moron.

If it comes from Thomas, don't believe anything he says until you see it
and understand it for yourself. He seems to think he is some kind of
Einstein/NetCop but he's a complete idiot in that regards.

 

[matty]

You are not the moron.

Thanks

And whether you use that language attribute or not will be dependent on
what behavior you are looking for. But to understand that behavior, and
whether you want it or not, you have to understand the behaviors
themselves. And once you understand them, the question becomes moot.

No. The question is not moot. The question is: a MAJOR website is
telling me that I should use the "language="javascriptx.x" to expect a
specific behavior. People here tell me that I shouldn't follow the
rules of the MAJOR website (my MAJOR I mean a website like Mozilla,
which is supposedly following the standards). So yes, I am confused.

The W3C tells you to use the type attribute (but I have never cared what
W3C or ECMA say)

Why not? Aren't they supposed to be the standard? What do you care
about?

If it comes from Thomas, don't believe anything he says until you see it
and understand it for yourself. He seems to think he is some kind of
Einstein/NetCop but he's a complete idiot in that regards.

I disagree with his overall attitude in treating most of the posters as
total morons, but respect his knowledge and I have learned a lot by
reading him.

Matty.

 

[matty]

They already are (implicitly) telling you _not_ to use it.

Nonsense. Whether you use it or not depends on the behavior you want.

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

But to be in a position to decide the answer to that question, you have
to understand the consequences of that action and if you truly
understand the consequences, then the question becomes moot.

Maybe it's because people do not understand the consequences that they
ask questions in the first place.

Matty.