The &quot;undefined&quot; value

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.

Nov 23 '05 #2

matty wrote:

<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

Nov 23 '05 #3

matty

Luke Matuszewski wrote:

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.

Nov 23 '05 #4

matty wrote:

Luke Matuszewski wrote:
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.

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).

Nov 23 '05 #5

Luke Matuszewski wrote:

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

Nov 23 '05 #6

Luke Matuszewski wrote:

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

Nov 23 '05 #7

matty

Thomas 'PointedEars' Lahn wrote:

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.

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"'.

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

Nov 23 '05 #8

Thomas 'PointedEars' Lahn wrote:

(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.

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.

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.

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.

typeof true = "true"
typeof false = "false"
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.

Nov 23 '05 #9

Luke Matuszewski wrote:

[...] 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

Nov 23 '05 #10

Luke Matuszewski wrote:

Thomas 'PointedEars' Lahn wrote:
> (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.

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

Nov 23 '05 #11

Matt Kruse

Luke Matuszewski wrote:

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 ;)

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

Nov 23 '05 #12

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.

Nov 23 '05 #13

matty

Luke Matuszewski wrote:

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.

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

Nov 23 '05 #14

matty wrote:

Luke Matuszewski 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.
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

Nov 23 '05 #15

matty

Thomas 'PointedEars' Lahn wrote:

matty wrote:
Luke Matuszewski 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.
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.

Nov 23 '05 #16

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

matty wrote:

Luke Matuszewski 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.

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.

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
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Nov 23 '05 #17

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

Thomas 'PointedEars' Lahn wrote:
<snip>

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

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.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Nov 23 '05 #18

matty

> >

I must be a complete moron but when I read:
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?

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.

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.

Nov 23 '05 #19

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.

Nov 23 '05 #20

matty said the following on 11/20/2005 1:11 AM:

I must be a complete moron but when I read:
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.

In NS4.xx series browser (PC based, not sure about the MAC based ones)
the = sign is screwed up. It doesn't do what you think it is going to
do. It is a behavior of the browser/implementation. The browser isn't
wrong, per se, it just doesn't follow other browsers but it follows
exactly what Netscape said it would do. There are also problems in IE
with language versions (I can't recall one off the top of my head
though) whereby IE acts differently with different language versions.
The simple solution? Skip the language attribute, use the type attribute
(if you use either at all). Then, in 99.99% of browsers it will do what
you think it is going to do.

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?

ECMA is a theory about how things should be, not a reflection of how
they really are. What I care/worry about is what the browsers actually
*do*, not what they are *supposed* to do according to ECMA. If the
browser doesn't do what ECMA says, I don't care what ECMA says. I care
what actually happens. That's the difference between ECMA Theory and
Browser Reality.

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.

I disagree with his overall attitude in treating most of the posters as
total morons

Hence my description of him as a complete idiot when it comes to dealing
with people.
but respect his knowledge and I have learned a lot by reading him.

Thomas is a decent Theorist. If you want to learn a lot of theory then
read Richard Cornford. He is the best Theorist around here.

As for learning itself, read a lot of Martin Honnen as well.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Nov 23 '05 #21

matty said the following on 11/20/2005 1:16 AM:

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.

No, it is not a "standard" according to ECMA or W3C.

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.

True. Very true.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Nov 23 '05 #22

matty

> ECMA is a theory about how things should be, not a reflection of how

they really are. What I care/worry about is what the browsers actually
*do*, not what they are *supposed* to do according to ECMA. If the
browser doesn't do what ECMA says, I don't care what ECMA says. I care
what actually happens. That's the difference between ECMA Theory and
Browser Reality.
Agreed, but then when people tell me "this is how you should do it", I
tend to believe that they tell me to follow the ECMA standard, not what
a particular browser decided to implement it. I should then look at how
a browser has implemented it, and if it's not following the standard
then decide if I should work around it or forget it.

I disagree with his overall attitude in treating most of the posters as
total morons

Hence my description of him as a complete idiot when it comes to dealing
with people.

We agree on that :)

but respect his knowledge and I have learned a lot by reading him.
Thomas is a decent Theorist. If you want to learn a lot of theory then
read Richard Cornford. He is the best Theorist around here.

I'm a newbie on this group and I have formed my own opinion on the
regular posters. I respect both of them. Richard makes me think, Thomas
makes me think and laugh. Both are good.
As for learning itself, read a lot of Martin Honnen as well.

I will keep that in mind. Thank you.

Nov 23 '05 #23

matty said the following on 11/20/2005 2:53 AM:

> ECMA is a theory about how things should be, not a reflection of how
they really are. What I care/worry about is what the browsers actually
*do*, not what they are *supposed* to do according to ECMA. If the
browser doesn't do what ECMA says, I don't care what ECMA says. I care
what actually happens. That's the difference between ECMA Theory and
Browser Reality.

Agreed, but then when people tell me "this is how you should do it", I
tend to believe that they tell me to follow the ECMA standard, not what
a particular browser decided to implement it.

What do you do when ECMA doesn't specify how to do something though?
Case in point - How do you retrieve data from a server dynamically? The
buzzword for it is "AJAX" but an HTTPRequestObject is the least
supported way to do it. So then what?

I should then look at how a browser has implemented it, and if it's
not following the standard then decide if I should work around it or
forget it.

No browser will ever be 100% ECMA Compliant. When I say 100% I mean that
it follows everything in ECMA, implements it according to ECMA, and
nothing more. It will never happen. So, even if you know ECMA 100%, it
still won't be enough because you will still have to know how the
browsers deal with it. May as well learn the browser behavior and you
are set.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Nov 23 '05 #24

"matty" <un**********@gmail.com> writes:

The question is: a MAJOR website is telling me that I should use the
"language="javascriptx.x" to expect a specific behavior.
They are saying that *if* you need a specific behavior (which almost
always means like JavaScript 1.2), *then* you have to use the language
attribute.

They are not telling you not to use the "type" attribute (as well they
shouldn't, since it is mandatory for W3C standard compliant HTML).

They are perhaps also forgetting to tell you that the language
attribute trick only works in browsers that support more than one
dialect of JavaScript, and not just the most recent version of
ECMAScript. The browsers supporting multiple dialects include Netscape
4 (and earlier) and Mozilla based browsers. Maybe there are more, but
other major browsers like IE and Opera are not among them.

That means that depending on a specific older versions' behavior will
break on pages used on the internet, if viewed in IE or Opera.

This is why people in this group recommends not using the language
attribute at all. The only effect you can get from using it is to
allow scripts that will break anyway.

Also, the most common use of it that we observe is people writing
language="JavaScript1.2" *without* knowing that it selects a different
interpretation of the script in *some* browsers, or what the difference
is. So unless a person can argue exactly why he needs it and that he
knows what he's doing, it's recommended that he avoids using the
"language" attribute.
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).

The Mozilla page, which I haven't read recently, is probably doing its
job: documenting the behavior of Mozilla. And indeed, if you want
Mozilla to select a different dialect of Javascript, this is the way
to do it.

We are telling you that you don't want to want that. :)

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

Nov 23 '05 #25

Randy Webb <Hi************@aol.com> writes:

No browser will ever be 100% ECMA Compliant. When I say 100% I mean
that it follows everything in ECMA, implements it according to ECMA,
and nothing more.
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".

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."
It will never happen. So, even if you know ECMA 100%, it still won't
be enough because you will still have to know how the browsers deal
with it. May as well learn the browser behavior and you are set.

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.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

Nov 23 '05 #26

I would like still to answer to the OP question (as it seemed to be not
aswered yet)

undefined value is a special kind of value: it returned by system is
you are trying to address a recourses which never was initialized,
doesn't exists, is out of the scope of the current execution context.

document.NonExistingProperty gives you undefined
arr = new Array(1,2,3); arr[1024] gives you undefined
etc.

Non-existence has no *value* in the common programming sense, like
vacuum doesn't have a temperature. But developers needed an easy way to
check for non-existence in their programs so they have this method:
if (typeof(obj) == "undefined") { //doesn't exists
[A note to purists: typeof doesn't require parenthesis but it doesn't
explicetly prohibits them heither. If you're using a compactor for your
scripts, implied parenthesis help greatly to keep your script stable
after compacting]

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:

myObject.myProperty = undefined;
alert("myProperty" in myObject); // true

So we have myProperty which exists and initialized with the value of
non-existence.

IMHO one should cut some body parts off for this.

Nov 23 '05 #27

matty wrote:

Thomas 'PointedEars' Lahn wrote:
matty wrote:
> Luke Matuszewski 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.
> 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.

You are just falsely inferring things that are not expressed. There is a
difference between "using this you can achieve that" and "you have to use
this to achieve anything". The Web site does the former, not the latter.
HTH

PointedEars

Nov 23 '05 #28

VK wrote:

I would like still to answer to the OP question (as it seemed to be not
aswered yet)
It was answered in great detail by more than one person, including
me. But, as you wrote, you decided to filter postings of all those
people far more competent than you (by technology or just ignorance
when reading) because their expertise does not fit your narrow view
of the world.
undefined value is a special kind of value: it returned by system is
you are trying to address a recourses which never was initialized,
doesn't exists, is out of the scope of the current execution context.
Or was assigned it.
document.NonExistingProperty gives you undefined
arr = new Array(1,2,3); arr[1024] gives you undefined
etc.

Non-existence has no *value* in the common programming sense,
in ECMAScript implementations.
like vacuum doesn't have a temperature.
Vacuum does have a temperature. Stop writing about things you don't have
a single clue of.
But developers needed an easy way to
check for non-existence in their programs so they have this method:
if (typeof(obj) == "undefined") { //doesn't exists
That is no test of non-existence was already pointed out.
[A note to purists: typeof doesn't require parenthesis but it doesn't
explicetly prohibits them heither. If you're using a compactor for your
scripts, implied parenthesis help greatly to keep your script stable
after compacting]
It remains to be discussed whether compactors really compact code as they
have to insert semicolons where otherwise automatic semicolon insertion
would have sufficed.

In this particular case, the "compact" argument is void:
`typeof(foo)<white-space>' needs potentially more, and certainly no less,
data space than the `typeof<white-space>foo<white-space>' sequence. The
trailing white-space character would be needed as newline to facilitate
automatic semicolon insertion if no further expressions followed on that
line and the `typeof' operation is used on the right-hand side of an
expression; it would be needed as general white-space in place of the
`)' character if other expressions followed there.
This situation was fully satisfying for everyone except some bored
academical minds.
Given your continuing presentation of utter nonsense as the Holy Truth
caused by wild assumptions on your part caused by general misconceptions
on your part on how things really work in computer science, those "bored
academical minds" apparently gathered more knowledge than apparently you
will be ever capable of.
These minds did not like the fact that there is something that has a
string representation ("undefined") but is not represented per se.
You are not making any sense. "undefined" != undefined, literally.
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:
Nonsense. There is nothing buggy about it.
myObject.myProperty = undefined;
alert("myProperty" in myObject); // true

So we have myProperty which exists and initialized with the value of
non-existence.
As I and others have said, `undefined' is _not_ the value of non-existence.
Which is why your precious, little supported `in' operator _correctly_
yields `true' as the hasOwnProperty() method does.
IMHO one should cut some body parts off for this.

IMHO you should be forbidden to post further nonsense here in the way that
you do.
PointedEars

Nov 23 '05 #29

matty wrote:

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.

<snip>

As it has been explained to me (and I can see no reason for doing the
historical research that would confirm the details) at the point when
JavaScript(tm) 1.2 was released Netscape was committed to the
standardisation of the language and JavaScript(tm) 1.1 was already
conforming to (and extending) ECMA 262 1st edition. Netscape made
proposals for changes to the second edition of ECMA 262 that included
modifying the type-conversion rules and changing the behaviour of the
assignment operator to depend on the context of its use. They
implemented these changes in JavaScript 1.2 in anticipation of their
being accepted by the ECMA. Other ECMA members did not agree to the
changes and when ECMA 262 2nd edition was published it did not include
them. Netscape, being committed to the standardisation of the language,
reversed their changes in JavaScript 1.3 so that it complied with ECMA
262 2nd edition, but left their interpreter using the aberrant behaviour
of JavaScritp 1.2 when a SCRIPT element's LANGUAGE attribute was
explicitly set to version 1.2 (for back-compatibility).

Other language implementations never implemented this aberrant behaviour
but would still load and interpret scripts specified as
LANGUAGE="JavaScript1.2". Thus, if you use LANGUAGE="JavaScript1.2"
Netscape 4 versions, and potentially browsers employing the Rhino
Java-based JavaScript interpreter (such as browsers as recent as this
year's IceBrowser 6) may exhibit the aberrant behaviour of Netscape's
version 1.2, but other browser will not.

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_.

Without a LANGUAGE attribute (as commonly recommended here) all browsers
use the latest language interpretation and behaviour available. That is,
at minimum, likely to be behaviour conforming to ECMA 262 2nd edition,
and vary likely behaviour conforming to ECMA 262 3rd edition. Rhino, for
example, is currently an ECMA 262 3rd edition conforming implementation
(by default). The only browsers that will exhibit the aberrant behaviour
of JavaScript 1.2 when presented only with a TYPE attribute are Netscape
4 versions up to 4.06 (and serious security flaws in Netscape 4 mean
that using versions earlier than 4.6 is suicidal and not at all
encouraged, so those versions are unlikely to encountered in the wild
(indeed Netscape 4 is increasingly rarely seen at all)).

In purely practical terms, in 2005 specifying LANGUAGE="JavaScript1.2"
may introduce issues that are undesirable and can be completely avoid by
no more than not specifying LANGUAGE="JavaScript1.2". The recommendation
is to forget about the LANGUAGE attribute entirely and only use the
((x)HTML) required TYPE attribute.

Richard.

Nov 23 '05 #30

Randy Webb wrote:
<snip>

Thomas is a decent Theorist. If you want to learn a lot of
theory then read Richard Cornford. He is the best Theorist
around here.
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)?
As for learning itself, read a lot of Martin Honnen as well.

Absolutely, read every word he writes.

Richard.

Nov 23 '05 #31

As my final note on undefined in JavaScript, here are some examples:

var a; /* let as assume that only 'a' is stated in JavaScript code */

if(typeof a == "undefined") { alert(typeof cool); } /* will result in
alert with undefined text in it */

if(a == undefined) { alert(typeof cool); } /* will result in alert with
undefined text in it */

if(typeof a == undefined) { alert(typeof cool); } /* will NOT result
in alert box */

/* 'cool' identifier appeared just here in below statements and nowere
else */

if(typeof cool == "undefined") { alert(typeof cool); } /* will result
in alert with undefined text in it */

if(typeof cool == undefined) { alert(typeof cool); } /* will NOT result
in alert box */

if(cool == undefined) { alert(typeof cool); } /* will NOT result in
alert box */

So really 'undefinded' isn't a keyword and thus it may contain a value.
The line:
if(a == undefined) { alert(typeof cool); } /* will result in alert with
undefined text in it */
will work becouse of coercion rules defined in JavaScript, but it will
not work here
var a = 3;
var undefined = 4;
if(a == undefined) { alert(typeof cool); } /* will NOT result in alert
box */

I think that it clears everything...

Best regards.
Luke.

Nov 23 '05 #32

For those learning the JavaScript language like i am, the most 'major'
things to learn first is:
0) basics (operators, keywords, condidtional statements and so on),
- coercion rules defined in JavaScript. As a little example related
with undefined read this:
var a;
if(a == undefined) { alert(1); } /* [A] will result in alert box */
if(a == cool) { alert(2); } /* [b] will NOT result in alert box */
if(cool == undefined) { alert(3); } /* [C] will NOT result in alert
box */
if(cool == cool2) { alert(4); } /* [C] will NOT result in alert box */
alert(cool) /* will result in error - no definition of cool */
alert(a) /* will NOT show alert box but error will not be shown */

So it seems that with == you can test the specific situation - test
for the property/variable/function/... that was defined but not
assigned a value; two lines belowe shows that
var a;
if(a == undefined) { alert(1); } /* [A] will result in alert box */
if(cool == undefined) { alert(3); } /* [C] will NOT result in alert
box */
(if you will use only typeof and == with followed by string
representation of result of typeof you can't test this specific
situation). So:
if(a == undefined) {
/* here variable is defined, but not assigned a value */
}
if(typeof a = "undefined") {
/* here variable is defined, but not assigned a value or */
/* a variable is not defined anywhere (like 'cool' frome above
examples) */
}
if(a) {
/* here a is defined and has a proper value inside so it may contain
primitive value or reference to object */
}
- closures - which is most advanced part of JavaScript

- native EcmaScript objects (which belongs to language) and host
objects (provided by envirnoment - browser objects);

http://www.jibbering.com/faq/faq_notes/faq_notes.html
http://www.crockford.com/javascript/survey.html (and
http://www.crockford.com/javascript/)

Best regards.
Luke.

Nov 23 '05 #33

matty wrote:

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/programm...pt/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>
That is a rather superficial description in which the second statements
may be considered false and the implications of the first statement are
important but not explained.

ECMAScript has a primitive data type called undefined that has a single
value. When variables are 'created' (as properties of an
Activation/Variable object, during variable instantiation) they are
given a value that is of the primitive type called undefined, pending
the assignment of other values during code execution. Also, when
attempts are made to read the value of a property of an object, if the
object (or any of its prototypes) does not possess that property then
the value of the undefined primitive data type is returned, as required
by the internal [[Get]] method of all objects:-

<quote cite="ECMA 262 3rd edition: Section 8.6.2.1">
8.6.2.1 [[Get]] (P)

When the [[Get]] method of O is called with property name P, the
following steps are taken:

1. If O doesn't have a property with name P, go to step 4.
2. Get the value of the property.
3. Return Result(2).
4. If the [[Prototype]] of O is null, return undefined.
5. Call the [[Get]] method of [[Prototype]] with property name P.
6. Return Result(5).
</quote>

Because the undefined data type is a data type and has a (single) value
that value may be explicitly (or unintentionally) assigned to variables
and object properties by executing code. For example:-

var x = someObject.propertyThatItDoesNotHave;

- would result in the value of the undefined data type being assigned to
the variable x if - someObject - refers to an object that does not have
a property named 'propertyThatItDoesNotHave'.

Also, functions that do not explicitly return a value of a different
type (with a return statement that includes an expression to be
evaluated and the result returned) return the value of the undefined
data type by default. So:-

var x = (function(){;})();

- would also result in the value of the undefined data type being
assigned to the variable - x -.

It is the fact that you can explicitly assign the value of the undefined
data type to any variable/object property at any time that makes the
second statement above false. Verifying that a variable/object property
has a value that equates to the value of the undefined data type does
not actually imply that the variable/object property was not
initialized.

At some point is was seen as desirable to make the value of the
undefined data type explicitly available to javascript. To achieve this
a property of the global object was created and given the name
'undefined', and that property of the global object (and so effectively
global variable) was initialized to the value of the undefined data
type. (Making the 'undefined' global variable both defined and
initialized ;-)

This decision was formalised in the 3rd edition of ECMA 262 (see section
15.1.1.3).

It is the existence of this global variable with the name 'undefined'
that allows code such as that cited above:-

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

The variable - a - is evaluated to its value, and then the variable -
undefined - is evaluated to its value (which will be the value of the
undefined data type) and the two values are compared. Note, however,
that the value of the undefined data type equates to the value of the
null data type when the type-converting comparison operator is used. So
this test does not even indicate whether the value of - a - is the value
of the undefined data type or not.

Because of its relatively late inclusion in the language, the -
underfeed - global variable is problematic to use as shown above. In
browsers where the variable does not exist using the unqualified
identifier - undefined - will elicit run-time errors along the lines of
IE4's unhelpful '"undefined" is undefined' message. This can be avoided
by using a property accessor in place of the unqualified identifier,
e.g:-

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

And when the [[Get]] method of - window - does not find the property
name 'undefined' on the global/window object it will return the value of
the undefined data type anyway. Alternatively, a system can be rendered
'safe' by the explicit creation of a global - undefined - property
with:-

window.undefined = window.undefined;

- as that will not break systems where the - undefined - global variable
exists, and it will create one, with the correct value, where it does
not.

On the other hand, I don't recall ever using the - undefined - global
variable. Either - typeof - will tell me what I want to know, or the
tests I want to perform are such that its use is unnecessary.
Is this really valid?
Valid, but with caveats.
Shouldn't it be "if (typeof a == 'undefined') ?
Theoretically - typeof - plus the string comparison will not be as fast.
But if you think you need to test properties for undefined values so
often that the performance difference would be significant you are
probably doing something else wrong.
Would an explanation on what "undefined" is and how to check
for it be a good entry for the FAQ?

Maybe.

Richard.

Nov 23 '05 #34

VK wrote:

I would like still to answer to the OP question (as it
seemed to be not aswered yet)

undefined value is a special kind of value: it returned by
system is you are trying to address a recourses which never
was initialized, doesn't exists, is out of the scope of the
current execution context.
That is not really true. The use of Identifiers referring to the out of
scope and the non-existent are quite likely to produce run-time errors.
document.NonExistingProperty gives you undefined
arr = new Array(1,2,3); arr[1024] gives you undefined
etc.
Both attributable to the specified behaviour of the Object's [[Get]]
method.

But:-

var x = NonExistingProperty;

- produces a run-time error.
Non-existence has no *value* in the common programming
sense, like vacuum doesn't have a temperature.
One of the significant breakthroughs in the history of mathematics was
the realisation that zero is a value.
But developers needed an easy way to check for
non-existence in their programs so they have this method: if (typeof(obj) == "undefined") { //doesn't exists
But:-

if(typeof undefined == 'undefined') is true and it probably does exist.
[A note to purists: typeof doesn't require parenthesis but
it doesn't explicetly prohibits them heither.
It is not a question of allowing or forbidding parentheses. The -
typeof - operator is unary so it only accepts one expression as its
operand. If you use parenthesise then that expression is a
PrimarilyExpression formed by the Grouping operator (the parenthesise)
and no longer the expression within the grouping operator.
If you're using a compactor for your scripts, implied
parenthesis help greatly to keep your script stable after
compacting]
Taking the above use of - typeof - and reducing it to the minimum that
can be reliably tokenised you get:-

if(typeof(obj)=="undefined"){

- While not using the redundant grouping operator (the parenthesise)
around - obj - yields:-

if(typeof obj=="undefined"){

- and is one character shorter. So your suggestion doesn't look valid
for reasons of code compacting. And in you quest for irrelevant
nanosecond improvements in performance have you considered the impact of
evaluating the unnecessary Grouping operation?

If explicit parenthesise are important to script compacting software
then that software is significantly flawed and likely to break scripts
passed through it.
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.

<snip>

You are making this all up off the top of your head, again.

Richard.

Nov 23 '05 #35

Ok i see my assumptions was wrong. Line:

if(a == undefined) {
/* here variable is defined, but not assigned a value */
}
should be
window.undefined = window.undefined;
if(a == window.undefined) {
/* here variable is defined and assigned a value of undefined (but probably 'a' variable in past contained other values/references */
} ( * 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 )

Richard Cornford wrote:
Note, however, that the value of the undefined data type equates to the value of the null data type when the type-converting comparison operator is used. If so, then for strictlier comparision i should use: window.undefined = window.undefined;
if(a === window.undefined) {
/* here variable is defined and assigned a value of undefined (but probably 'a' variable in past contained other values/references */
}

Best regards.

Nov 23 '05 #36

Luke Matuszewski wrote:

As my final note on undefined in JavaScript, here are some examples:

var a; /* let as assume that only 'a' is stated in JavaScript code */

if(typeof a == "undefined") { alert(typeof cool); } /* will result in
alert with undefined text in it */
If, and only if (iff), `a' was not assigned a value different from
`undefined'.
if(a == undefined) { alert(typeof cool); } /* will result in alert with
undefined text in it */
Iff `a' was declared before or is otherwise in the scope chain.
if(typeof a == undefined) { alert(typeof cool); } /* will NOT result
in alert box */
Because the _string_ value the TypeOfExpression evaluates to ("undefined")
is not the same than `undefined'. No surprise here.
/* 'cool' identifier appeared just here in below statements and nowere
else */
Whether it appeared is not relevant. Whether it was instantiated or not
and what its current value is, is relevant.
if(typeof cool == "undefined") { alert(typeof cool); } /* will result
in alert with undefined text in it */
with `undefined' _as_ text
if(typeof cool == undefined) { alert(typeof cool); } /* will NOT result
in alert box */
Because of two values that are not the same.
if(cool == undefined) { alert(typeof cool); } /* will NOT result in
alert box */
Because, iff `cool' was not instantiated, the code will error.
Because, iff `cool' was instantiated, its value was different
from `undefined'.
So really 'undefinded' isn't a keyword and thus it may contain a value.
True. However, as I recall, nobody ever said it was. Instead, it was
explicitly and correctly stated to be a property of the Global Object.
The line:
if(a == undefined) { alert(typeof cool); } /* will result in alert with
undefined text in it */
Iff `a' was instantiated and has `undefined' as its current value.
will work becouse of coercion rules defined in JavaScript, but it will
not work here
var a = 3;
var undefined = 4;
if(a == undefined) { alert(typeof cool); } /* will NOT result in alert
box */
Because _any_ non-abstract property of built-in objects can be overwritten,
including the `undefined' property of the Global Object. No surprises here.
I think that it clears everything...

I think without additional comments like I did, your posting causes more
confusion than it prevents.
PointedEars

Nov 23 '05 #37

Luke Matuszewski wrote:

For those learning the JavaScript language like i am, the most 'major'
things to learn first is:
0) basics (operators, keywords, condidtional statements and so on),
- coercion rules defined in JavaScript. As a little example related
with undefined read this:
So far for your "final note"
(news:11*********************@g14g2000cwa.googlegr oups.com) ...

You are merely demonstrating your misconceptions about the language. If
you do not want to be considered the next VK, I suggest you stop posting
like that and read any reference material first.
var a;
if(a == undefined) { alert(1); } /* [A] will result in alert box */
Because `a' was declared before. If it had not been, the code would
have _errored_ with:

| ReferenceError: a is not defined
if(a == cool) { alert(2); } /* [b] will NOT result in alert box */
Because `cool' is not a variable identifier or otherwise in the scope:

| ReferenceError: cool was not defined
if(cool == undefined) { alert(3); } /* [C] will NOT result in alert
box */
If not, then either because of the (same) error (as) above or because of
`cool' having a different value than `undefined'.
if(cool == cool2) { alert(4); } /* [C] will NOT result in alert box */
What are you trying to prove? That errors can break otherwise working
script code? Congratulations.
alert(cool) /* will result in error - no definition of cool */
True, and it will do so correctly.
alert(a) /* will NOT show alert box but error will not be shown */
False. It will show `undefined' provided that execution has continued
to this line because `a' was declared above. If `a' was not declared
or execution has not continued down to here, you know who to blame.
So it seems that with == you can test the specific situation - test
for the property/variable/function/... that was defined but not
assigned a value; two lines belowe shows that
var a;
if(a == undefined) { alert(1); } /* [A] will result in alert box */
if(cool == undefined) { alert(3); } /* [C] will NOT result in alert
box */
See above.
(if you will use only typeof and == with followed by string
representation of result of typeof you can't test this specific
situation).
You can. `typeof cool' will yield "undefined", unless `cool' was
defined otherwise.
So:
if(a == undefined) {
/* here variable is defined, but not assigned a value */
}
Nothing is defined here. It is simply a comparison operation.
if(typeof a = "undefined") {
/* here variable is defined, but not assigned a value or */
/* a variable is not defined anywhere (like 'cool' frome above
examples) */
}
There is no reason why either should happen. The TypeOfExpression takes
precedence over the AssignmentExpression, as in `(typeof a) = "undefined"'.
Since the `typeof' operator is used left-hand side which it is not allowed
to, the above correctly results in

| SyntaxError: invalid assignment left-hand side
if(a) {
/* here a is defined and has a proper value inside so it may contain
primitive value or reference to object */
}

`a' was declared (not [yet]: defined), i.e. has the false-value `undefined',
which is why the conditional expression evaluates to `false' and the
BlockStatement is not evaluated.

Iff we assume `a' was instantiated before, the BlockStatement is only
evaluated if `a' is a true-value.
PointedEars

Nov 23 '05 #38

Richard Cornford wrote:

VK wrote:
Non-existence has no *value* in the common programming
sense, like vacuum doesn't have a temperature.

One of the significant breakthroughs in the history of
mathematics was the realisation that zero is a value.

*g*

However, due to several factors it is not possible to reach 0 K(elvin) :)
Regards,
PointedEars

Nov 23 '05 #39

Luke Matuszewski wrote:

Ok i see my assumptions was wrong. Line:
if(a == undefined) {
/* here variable is defined, but not assigned a value */
}
should be
window.undefined = window.undefined;
if(a == window.undefined) {
/* here variable is defined and assigned a value of undefined (but
probably 'a' variable in past contained other values/references */ }

( * so there is no programmical way to test if variable was defined but
not assigned a value [...]

different from the `undefined' value. Provided that the `undefined'
property is either built-in or user-defined to contain the `undefined'
value (for brevity of this example),

var a;

and

var a = undefined;

and

var a;
a = undefined;

are equivalent.
... but i assume there is no need to )
The available testing methods for the language sufficed for me to date.
Richard Cornford wrote:

Note, however, that the value of the undefined data type equates to the
value of the null data type when the type-converting comparison operator
is used.

If so, then for strictlier comparision i should use:
window.undefined = window.undefined;
if(a === window.undefined) {
/* here variable is defined and assigned a value of undefined (but
probably 'a' variable in past contained other values/references */ }

This is hardly legible. Would you care to include empty lines?
PointedEars

Nov 23 '05 #40

Thomas 'PointedEars' Lahn napisal(a):

Richard Cornford wrote:

Note, however, that the value of the undefined data type equates to the
value of the null data type when the type-converting comparison operator
is used. If so, then for strictlier comparision i should use:
window.undefined = window.undefined;
if(a === window.undefined) {
/* here variable is defined and assigned a value of undefined (but
probably 'a' variable in past contained other values/references */ }

This is hardly legible. Would you care to include empty lines?

Will think of it in next of my posts (will try harder to make my posts
more legible).
PointedEars

Thanks for answering.
It would be great that other groups i am interested in would reply that
fast (eg. comp.lang.java.security).
Luke M.

Nov 23 '05 #41

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.

Nov 23 '05 #42

Martin Honnen

Richard Cornford wrote:

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.

--

Martin Honnen
http://JavaScript.FAQTs.com/

Nov 23 '05 #43

John G Harris

In article <11**********************@g47g2000cwa.googlegroups .com>, VK
<sc**********@yahoo.com> writes

<snip>

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
--
John Harris

Nov 23 '05 #44

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

Randy Webb wrote:
<snip>
Thomas is a decent Theorist. If you want to learn a lot of
theory then read Richard Cornford. He is the best Theorist
around here.

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
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Nov 23 '05 #45

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

Randy Webb <Hi************@aol.com> writes:

No browser will ever be 100% ECMA Compliant. When I say 100% I mean
that it follows everything in ECMA, implements it according to ECMA,
and nothing more.

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 :)

It will never happen. So, even if you know ECMA 100%, it still won't
be enough because you will still have to know how the browsers deal
with it. May as well learn the browser behavior and you are set.

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.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Nov 23 '05 #46

"matty" <un**********@gmail.com> writes:

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
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

Nov 23 '05 #47

Luke Matuszewski wrote:

Richard Cornford has wrote great part of what i expected.
What are you referring to?
<URL:http://jibbering.com/faq/faq_notes/pots1.html#ps1Post>
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

Nov 23 '05 #48

Dr John Stockton

JRS: In article <11**********************@g14g2000cwa.googlegroups .com>
, dated Sun, 20 Nov 2005 08:30:00, seen in news:comp.lang.javascript,
Luke Matuszewski <ma****************@gmail.com> posted :

( * 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.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

Nov 23 '05 #49