The "undefined" value

R

Randy Webb

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




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

Randy Webb

matty said the following on 11/20/2005 1:16 AM:
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.
Maybe it's because people do not understand the consequences that they
ask questions in the first place.

True. Very true.
 
M

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.
Hence my description of him as a complete idiot when it comes to dealing
with people.

We agree on that :)
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.
 
R

Randy Webb

matty said the following on 11/20/2005 2:53 AM:
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.
 
L

Lasse Reichstein Nielsen

matty said:
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
 
L

Lasse Reichstein Nielsen

Randy Webb said:
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
 
V

VK

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

Thomas 'PointedEars' Lahn

VK said:
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
 
R

Richard Cornford

matty said:
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.
 
R

Richard Cornford

Randy Webb wrote:
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.
 
L

Luke Matuszewski

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

Luke Matuszewski

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); } /* 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.
 
R

Richard Cornford

matty said:
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>

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

Richard Cornford

VK said:
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.
 
L

Luke Matuszewski

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 said:
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.
 
T

Thomas 'PointedEars' Lahn

Luke said:
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
 
T

Thomas 'PointedEars' Lahn

Luke said:
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"
(...

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); } /* 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
 
T

Thomas 'PointedEars' Lahn

Richard said:
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
 
T

Thomas 'PointedEars' Lahn

Luke said:
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.
If so, then for strictlier comparision i should use:

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


PointedEars
 
L

Luke Matuszewski

Thomas 'PointedEars' Lahn napisal(a):
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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top