Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #14191 > unrolled thread

Difference between == and ===?

Back to article view | Back to comp.lang.javascript

Contents

  Difference between == and ===? Jason Kim <iamjsonkim@gmail.com> - 2012-05-28 20:19 -0700
    Re: Difference between == and ===? Jason Kim <iamjsonkim@gmail.com> - 2012-05-28 21:46 -0700
      Re: Difference between == and ===? "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2012-05-29 08:20 +0300
        Re: Difference between == and ===? Jason Kim <iamjsonkim@gmail.com> - 2012-05-29 07:56 -0700
          Re: Difference between == and ===? "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2012-05-29 19:15 +0300
            Re: Difference between == and ===? Jason Kim <iamjsonkim@gmail.com> - 2012-05-29 10:35 -0700
              Re: Difference between == and ===? "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2012-05-29 21:52 +0300
              Re: Difference between == and ===? Gregor Kofler <usenet@gregorkofler.com> - 2012-05-29 21:34 +0200
              Re: Difference between == and ===? Dr J R Stockton <reply1222@merlyn.demon.co.uk.not.invalid> - 2012-05-30 19:53 +0100
                Re: Difference between == and ===? Scott Sauyet <scott.sauyet@gmail.com> - 2012-05-31 04:52 -0700
                  Re: Difference between == and ===? Dr J R Stockton <reply1222@merlyn.demon.co.uk.not.invalid> - 2012-06-01 21:41 +0100
      Re: Difference between == and ===? Gregor Kofler <usenet@gregorkofler.com> - 2012-05-29 09:34 +0200
        Re: Difference between == and ===? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-05-29 14:13 +0200
          Re: Difference between == and ===? Jason Kim <iamjsonkim@gmail.com> - 2012-05-29 08:08 -0700
            Re: Difference between == and ===? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-05-29 17:32 +0200
              Re: Difference between == and ===? Jason Kim <iamjsonkim@gmail.com> - 2012-05-29 08:50 -0700
            Re: Difference between == and ===? "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-05-29 16:26 +0000
              Re: Difference between == and ===? Jason Kim <iamjsonkim@gmail.com> - 2012-05-29 10:36 -0700
                Re: Difference between == and ===? Scott Sauyet <scott.sauyet@gmail.com> - 2012-05-29 10:52 -0700
                Re: Difference between == and ===? "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-05-29 21:50 +0000
                  Re: Difference between == and ===? "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2012-05-30 07:46 +0300
                    Re: Difference between == and ===? "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-05-30 07:48 +0000
                      Re: Difference between == and ===? "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2012-05-30 11:08 +0300
                        Re: Difference between == and ===? "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-05-30 14:36 +0000
                        Re: Difference between == and ===? John G Harris <john@nospam.demon.co.uk> - 2012-05-30 15:26 +0100
                          Re: Difference between == and ===? "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2012-05-30 20:17 +0300
                            Re: Difference between == and ===? John G Harris <john@nospam.demon.co.uk> - 2012-06-01 14:54 +0100
                              Re: Difference between == and ===? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-01 13:09 -0700
                                Re: Difference between == and ===? Gene Wirchenko <genew@ocis.net> - 2012-06-01 13:49 -0700
                                  Re: Difference between == and ===? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-06-01 14:21 -0700
                                Re: Difference between == and ===? John G Harris <john@nospam.demon.co.uk> - 2012-06-03 11:41 +0100
                                  Re: Difference between == and ===? Dr J R Stockton <reply1223@merlyn.demon.co.uk.not.invalid> - 2012-06-04 20:02 +0100
                                    Re: Difference between == and ===? BGB <cr88192@hotmail.com> - 2012-06-05 10:06 -0500
                                      Re: Difference between == and ===? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-06-05 18:12 +0000
                                        Re: Difference between == and ===? BGB <cr88192@hotmail.com> - 2012-06-05 21:23 -0500
                                          Re: Difference between == and ===? Norman Peelman <npeelmandog@cfl.rr.com> - 2012-06-05 23:16 -0400
                                            Re: Difference between == and ===? "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2012-06-06 07:55 +0300
                                        Re: Difference between == and ===? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-06-06 08:27 +0200
                                          Re: Difference between == and ===? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-06-06 21:22 +0200
                                        Re: Difference between == and ===? Dr J R Stockton <reply1223@merlyn.demon.co.uk.not.invalid> - 2012-06-06 18:56 +0100
                                          Re: Difference between == and ===? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-06-07 07:12 +0000
                                            Re: Difference between == and ===? Dr J R Stockton <reply1223@merlyn.demon.co.uk.not.invalid> - 2012-06-08 20:11 +0100
                                              Re: Difference between == and ===? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-06-09 14:22 +0000
                                      Re: Difference between == and ===? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-06-06 08:28 +0200
                                        Re: Difference between == and ===? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-06-06 09:51 +0000
                                          Re: Difference between == and ===? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-06-06 21:22 +0200
                                        Re: Difference between == and ===? BGB <cr88192@hotmail.com> - 2012-06-06 08:35 -0500
                                          Re: Difference between == and ===? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-06-06 21:19 +0200
                    Re: Difference between == and ===? John G Harris <john@nospam.demon.co.uk> - 2012-05-30 15:07 +0100
    Re: Difference between == and ===? John G Harris <john@nospam.demon.co.uk> - 2012-05-30 15:44 +0100
    Re: Difference between == and ===? Stefan Weiss <krewecherl@gmail.com> - 2012-06-01 10:05 +0200
      Re: Difference between == and ===? Ross McKay <au.org.zeta.at.rosko@invalid.invalid> - 2012-06-01 20:05 +1000
      Re: Difference between == and ===? "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-06-01 15:56 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#14229

2012-05-30 0:50, Evertjan. wrote:

> == This is the equal operator and returns a boolean true if both the
> operands are equal. JavaScript will attempt to convert different data types
> to the same type in order to make the comparison.
>
> === This is the strict equal operator and only returns a boolean true if
> both the operands are equal and of the same type.
>
> <http://www.devguru.com/technologies/ecmascript/quickref/comparison_operato
> rs.html>

Unfortunately, even the ECMAScript standard uses such misleading terms 
(though spelled as "equals operator" and "strict equals operator").

The "equals operator" tests for similarity of a specific kind. The 
"strict equals operator" corresponds to the intuitive notion of equality 
(identity of values).

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

[toc] | [prev] | [next] | [standalone]

#14231

Jukka K. Korpela wrote on 30 mei 2012 in comp.lang.javascript:

> 2012-05-30 0:50, Evertjan. wrote:
> 
>> == This is the equal operator and returns a boolean true if both the
>> operands are equal. JavaScript will attempt to convert different data
>> types to the same type in order to make the comparison.
>>
>> === This is the strict equal operator and only returns a boolean true
>> if both the operands are equal and of the same type.
>>
>> <http://www.devguru.com/technologies/ecmascript/quickref/comparison_op
>> erato rs.html>
> 
> Unfortunately, even the ECMAScript standard uses such misleading terms
> (though spelled as "equals operator" and "strict equals operator").

Quite apopriately named for what it means.

"equality operator" would perhaps linguistically be more correct, 
but that is not a spelling error.
 
> The "equals operator" tests for similarity of a specific kind. The 
> "strict equals operator" corresponds to the intuitive notion of
> equality (identity of values).

What nonsense, programmes sometimes correspond,
but certainly have no "intuitive notion".

Jukka, The explzanation of Devguru is quite nice and correct,
not "misleading" at all.

It explains that the only difference is the allowing or not allowing for 
different data type conversion, often called "strictness".

An "identity operator" would also/only need to check if the variable is 
one and the same, a "equality operator" allows values from different 
variables.

Indeed, the operators act as "identity operators" when comparing objects 
in Javascript.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#14232

2012-05-30 10:48, Evertjan. ẃrote:

>> Unfortunately, even the ECMAScript standard uses such misleading terms
>> (though spelled as "equals operator" and "strict equals operator").
>
> Quite apopriately named for what it means.

Not appropriately at all. As Crockford duly points out (and even the 
standard mentions this), the "==" operator isn't even transitive. (That 
is, a == b and b == c do not necessarily imply a == c.) So it does not 
even express an equivalence relation.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

[toc] | [prev] | [next] | [standalone]

#14235

Jukka K. Korpela wrote on 30 mei 2012 in comp.lang.javascript:

> 2012-05-30 10:48, Evertjan. ẃrote:
> 
>>> Unfortunately, even the ECMAScript standard uses such misleading terms
>>> (though spelled as "equals operator" and "strict equals operator").
>>
>> Quite apopriately named for what it means.
> 
> Not appropriately at all. As Crockford duly points out (and even the 
> standard mentions this), the "==" operator isn't even transitive. (That 
> is, a == b and b == c do not necessarily imply a == c.) So it does not 
> even express an equivalence relation.

So every imperfection of javascript execution makes a function apopriately 
named?

What is "the standard" of Javascript?

I submit that automatic type-conversion can never be reversive, 
as the programming sequence cannot be mirrored exactly,
"transitive" in your words, 
but that only hurts in extremely rare cases. 

Why that merits the word "even" escapes me.

Overall, automatic typeconverion is very usefull to the better programmer,
who klows the limitations. 

Isn't that what practical programming is all about?

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#14238

On Wed, 30 May 2012 at 11:08:18, in comp.lang.javascript, Jukka K.
Korpela wrote:
>2012-05-30 10:48, Evertjan. 0 >
>>> Unfortunately, even the ECMAScript standard uses such misleading terms
>>> (though spelled as "equals operator" and "strict equals operator").
>>
>> Quite apopriately named for what it means.
>
>Not appropriately at all. As Crockford duly points out (and even the
>standard mentions this), the "==" operator isn't even transitive. (That
>is, a == b and b == c do not necessarily imply a == c.) So it does not
>even express an equivalence relation.

More crock from Crockford. If someone wants to treat both Null and
undefined as the same kind of emptiness then why the hell shouldn't
they? In that case an equality operator that says they are equal is
perfectly respectable. (Especially as there is no sane reason why they
are two different types/values).

As for transitivity, if you want to compare apples with pears and pears
with oranges then you must expect anomalies.

  John
-- 
John Harris

[toc] | [prev] | [next] | [standalone]

#14240

2012-05-30 17:26, John G Harris wrote:

> If someone wants to treat both Null and
> undefined as the same kind of emptiness then why the hell shouldn't
> they?

Oh, be my guest! But it’s inadequate to call it equality.

Similarly, be my guest if you want to compare two decimal numbers for 
being almost the same, e.g. by checking whether their difference is less 
than 1E-6, or something. It can be more useful than comparing decimal 
numbers for equality. But it would be inadequate to call such closeness 
equality.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

[toc] | [prev] | [next] | [standalone]

#14270

On Wed, 30 May 2012 at 20:17:43, in comp.lang.javascript, Jukka K. 
Korpela wrote:
>2012-05-30 17:26, John G Harris wrote:
>
>> If someone wants to treat both Null and
>> undefined as the same kind of emptiness then why the hell shouldn't
>> they?
>
>Oh, be my guest! But it’s inadequate to call it equality.
   <snip>

Whether it's proper or not depends on the program's requirements.

null means the absence of an object; undefined means the absence of 
anything. In places where a primitive value is not permitted, the 
absence of anything means exactly the same as the absence of an object. 
In these circumstances
   undefined == null
is both sensible and proper, and in no way inadequate (whatever that 
means).

   John

PS If you're brave you'll attempt to explain why the language has these 
two different values.
-- 
John Harris

[toc] | [prev] | [next] | [standalone]

#14271

On 6/1/12 6:54 AM, John G Harris wrote:
> On Wed, 30 May 2012 at 20:17:43, in comp.lang.javascript, Jukka K.
> Korpela wrote:
>> 2012-05-30 17:26, John G Harris wrote:
>>
>>> If someone wants to treat both Null and
>>> undefined as the same kind of emptiness then why the hell shouldn't
>>> they?
>>
>> Oh, be my guest! But it’s inadequate to call it equality.
> <snip>
>
> Whether it's proper or not depends on the program's requirements.
>
> null means the absence of an object; undefined means the absence of
> anything. In places where a primitive value is not permitted, the
> absence of anything means exactly the same as the absence of an object.
> In these circumstances
> undefined == null
> is both sensible and proper, and in no way inadequate (whatever that
> means).
>
> John
>
> PS If you're brave you'll attempt to explain why the language has these
> two different values.

To me, null has a specific meaning, which is different than undefined. 
I'm not sure of the history of the two in JavaScript, but as far as 
semantics, null *is* a specific value with a specific type (the null 
type, which is assignable to most static types, but not assignable from 
any).  Undefined in more statically typed languages would be a syntax 
error.  For many everyday purposes in JavaScript, the distinction isn't 
important, but there are cases where the distinction means a lot.

Imagine an "optional" parameter, but "null" is actually a valid value. 
undefined would mean "use the default", where "null" means "use-nothing".

---
Daniel.

[toc] | [prev] | [next] | [standalone]

#14272

On Fri, 01 Jun 2012 13:09:25 -0700, Daniel Pitts
<newsgroup.nospam@virtualinfinity.net> wrote:

>On 6/1/12 6:54 AM, John G Harris wrote:

[snip]

>> PS If you're brave you'll attempt to explain why the language has these
>> two different values.

     You are evil, and on a Friday, too!  <BEG>

>To me, null has a specific meaning, which is different than undefined. 
>I'm not sure of the history of the two in JavaScript, but as far as 
>semantics, null *is* a specific value with a specific type (the null 
>type, which is assignable to most static types, but not assignable from 
>any).  Undefined in more statically typed languages would be a syntax 
>error.  For many everyday purposes in JavaScript, the distinction isn't 
>important, but there are cases where the distinction means a lot.
>
>Imagine an "optional" parameter, but "null" is actually a valid value. 
>undefined would mean "use the default", where "null" means "use-nothing".

     How do you use nothing and not have it be a default?

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#14273

On 6/1/12 1:49 PM, Gene Wirchenko wrote:
> On Fri, 01 Jun 2012 13:09:25 -0700, Daniel Pitts
> <newsgroup.nospam@virtualinfinity.net>  wrote:
>
>> On 6/1/12 6:54 AM, John G Harris wrote:
>
> [snip]
>
>>> PS If you're brave you'll attempt to explain why the language has these
>>> two different values.
>
>       You are evil, and on a Friday, too!<BEG>
>
>> To me, null has a specific meaning, which is different than undefined.
>> I'm not sure of the history of the two in JavaScript, but as far as
>> semantics, null *is* a specific value with a specific type (the null
>> type, which is assignable to most static types, but not assignable from
>> any).  Undefined in more statically typed languages would be a syntax
>> error.  For many everyday purposes in JavaScript, the distinction isn't
>> important, but there are cases where the distinction means a lot.
>>
>> Imagine an "optional" parameter, but "null" is actually a valid value.
>> undefined would mean "use the default", where "null" means "use-nothing".
>
>       How do you use nothing and not have it be a default?
>
> Sincerely,
>
> Gene Wirchenko

Default behavior might be to do "something", where you can override it 
to do "something else", or "nothing at all".

So, for example:  if (optionalSomething === undefined) 
defaultSomething() else if (optionalSomething !== null) optionSomething();

[toc] | [prev] | [next] | [standalone]

#14299

On Fri, 1 Jun 2012 at 13:09:25, in comp.lang.javascript, Daniel Pitts
wrote:

  <snip>
>Imagine an "optional" parameter, but "null" is actually a valid value.
>undefined would mean "use the default", where "null" means "use-
>nothing".

As I said, there can be circumstances where you need to tell null and
undefined apart. (Though I think it's unusual).

Are you sure that two special values are enough ? How about an
additional null1 and null2 ?

  John
-- 
John Harris

[toc] | [prev] | [next] | [standalone]

#14325

In comp.lang.javascript message <JRUUbNIW9zyPFwG+@J.A830F0FF37FB96852AD0
8924D9443D28E23ED5CD>, Sun, 3 Jun 2012 11:41:26, John G Harris
<john@nospam.demon.co.uk> posted:

>On Fri, 1 Jun 2012 at 13:09:25, in comp.lang.javascript, Daniel Pitts
>wrote:
>
>  <snip>
>>Imagine an "optional" parameter, but "null" is actually a valid value.
>>undefined would mean "use the default", where "null" means "use-
>>nothing".
>
>As I said, there can be circumstances where you need to tell null and
>undefined apart. (Though I think it's unusual).

N.B. undefined means "nothing has been written here", whereas null means
"'_nothing_' HAS been written here".  One is a negative, the other a
positive.

-- 
 (c) John Stockton, nr London UK  ?@merlyn.demon.co.uk  IE8 FF8 Op11 Sf5 Cr15
   news:comp.lang.javascript FAQ <http://www.jibbering.com/faq/index.html>.
   <http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
   <http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[toc] | [prev] | [next] | [standalone]

#14339

On 6/4/2012 2:02 PM, Dr J R Stockton wrote:
> In comp.lang.javascript message<JRUUbNIW9zyPFwG+@J.A830F0FF37FB96852AD0
> 8924D9443D28E23ED5CD>, Sun, 3 Jun 2012 11:41:26, John G Harris
> <john@nospam.demon.co.uk>  posted:
>
>> On Fri, 1 Jun 2012 at 13:09:25, in comp.lang.javascript, Daniel Pitts
>> wrote:
>>
>>   <snip>
>>> Imagine an "optional" parameter, but "null" is actually a valid value.
>>> undefined would mean "use the default", where "null" means "use-
>>> nothing".
>>
>> As I said, there can be circumstances where you need to tell null and
>> undefined apart. (Though I think it's unusual).
>
> N.B. undefined means "nothing has been written here", whereas null means
> "'_nothing_' HAS been written here".  One is a negative, the other a
> positive.
>


FWIW, I had generally interpreted it more like:
"null" means "there is no object here";
"undefined" means "this value is not valid".

[toc] | [prev] | [next] | [standalone]

#14340

BGB wrote on 05 jun 2012 in comp.lang.javascript:

> FWIW, I had generally interpreted it more like:
> "null" means "there is no object here";

"null" means a variable is not filled 
with an allowed type value. 

Not very usefull in JS variables, 
but usefull for a numeric database field.


> "undefined" means "this value is not valid".

"undefined" is a valid value of a variable in JS,
automagically assigned to a previously undefined variable,
and can be assigned to a existing variable.
 
-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#14344

On 6/5/2012 1:12 PM, Evertjan. wrote:
> BGB wrote on 05 jun 2012 in comp.lang.javascript:
>
>> FWIW, I had generally interpreted it more like:
>> "null" means "there is no object here";
>
> "null" means a variable is not filled
> with an allowed type value.
>
> Not very usefull in JS variables,
> but usefull for a numeric database field.
>

null seems "useful enough" IMO.

it is useful for whenever a person wants a variable which "doesn't 
reference an object" or "doesn't represent a value".


>
>> "undefined" means "this value is not valid".
>
> "undefined" is a valid value of a variable in JS,
> automagically assigned to a previously undefined variable,
> and can be assigned to a existing variable.
>

an "invalid value" does not mean it can't be found in a variable (say, 
due to it being uninitialized), or assigned to a variable, but rather 
just that it *represents* an invalid value.

[toc] | [prev] | [next] | [standalone]

#14346

On 06/05/2012 10:23 PM, BGB wrote:
> On 6/5/2012 1:12 PM, Evertjan. wrote:
>> BGB wrote on 05 jun 2012 in comp.lang.javascript:
>>
>>> FWIW, I had generally interpreted it more like:
>>> "null" means "there is no object here";
>>

   NULL is not an object, nor can it represent one.

>> "null" means a variable is not filled
>> with an allowed type value.
>>

   NULL does not define a type. NULL is nothing.

>> Not very usefull in JS variables,
>> but usefull for a numeric database field.
>>
>
> null seems "useful enough" IMO.
>
> it is useful for whenever a person wants a variable which "doesn't
> reference an object" or "doesn't represent a value".
>
>
>>
>>> "undefined" means "this value is not valid".
>>
>> "undefined" is a valid value of a variable in JS,
>> automagically assigned to a previously undefined variable,
>> and can be assigned to a existing variable.
>>
>
> an "invalid value" does not mean it can't be found in a variable (say,
> due to it being uninitialized), or assigned to a variable, but rather
> just that it *represents* an invalid value.
>

NULL literally means an absence of a value. It is not "" or 0 but will 
perform like a 0 in math computations (which may be un/desired).



-- 
Norman
Registered Linux user #461062
AMD64X2 6400+ Ubuntu 10.04 64bit

[toc] | [prev] | [next] | [standalone]

#14348

2012-06-06 6:16, Norman Peelman wrote:

> NULL is not an object, nor can it represent one.

"NULL" is an identifier with no meaning assigned to it in JavaScript 
definition (ECMAScript standard).

>>> "null" means a variable is not filled
>>> with an allowed type value.
>>>
>
> NULL does not define a type. NULL is nothing.

"NULL" is anything you define it to be in your code, whereas "Null" is a 
predefined type, having only value, namely "null", which by definition 
means the "primitive value that represents the intentional absence of 
any object value".

> NULL literally means an absence of a value.

"NULL" is as such an undefined identifier, whereas "null" is a special 
value of a special type. The formulation "representing the absence of an 
object value" means that "null" is intended for use in a context where 
objects are referred to and a special indicator of lack of object is needed.

A simple example is a linked list, where each item contains some data 
and a reference to the next item in the list. In the last item, the 
property for such a reference is set to the value "null" so that the end 
of the list can be determined. This value is different from not setting 
any value, or setting it to "undefined". (Although "undefined" could be 
used for indicating list end, it would not be good programming practice, 
since attempts to use "undefined" should normally be treated as errors, 
in order to make it easier to detect flaws in program logic, whereas the 
use of "null" is normal good practice.)

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

[toc] | [prev] | [next] | [standalone]

#14349

Evertjan. wrote:

> BGB wrote on 05 jun 2012 in comp.lang.javascript:
>> FWIW, I had generally interpreted it more like:
>> "null" means "there is no object here";
> 
> "null" means a variable is not filled
> with an allowed type value.
> 
> Not very usefull in JS variables,

Utter nonsense, all of the above.

> but usefull for a numeric database field.

True.

>> "undefined" means "this value is not valid".
> 
> "undefined" is a valid value of a variable in JS,

`undefined' is the solve value of the primitive Undefined type.

> automagically assigned to a previously undefined variable,

Variables are initialized with undefined unless assigned otherwise.

> and can be assigned to a existing variable.

… or property.


PointedEars
-- 
When all you know is jQuery, every problem looks $(olvable).

[toc] | [prev] | [next] | [standalone]

#14372

Thomas 'PointedEars' Lahn wrote:

> Evertjan. wrote:
>> BGB wrote on 05 jun 2012 in comp.lang.javascript:
>>> "undefined" means "this value is not valid".
>> "undefined" is a valid value of a variable in JS,
> 
> `undefined' is the solve value of the primitive Undefined type.

s/solve/sole/
 

PointedEars
-- 
Sometimes, what you learn is wrong. If those wrong ideas are close to the 
root of the knowledge tree you build on a particular subject, pruning the 
bad branches can sometimes cause the whole tree to collapse.
  -- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom@94.75.214.39>

[toc] | [prev] | [next] | [standalone]

#14373

In comp.lang.javascript message <XnsA069CD919A8F5eejj99@194.109.133.133>
, Tue, 5 Jun 2012 18:12:32, Evertjan. <exxjxw.hannivoort@inter.nl.net>
posted:

>
>"null" means a variable is not filled
>with an allowed type value.
>

But see ECMA 262 5.1 4.3.12.            // FF is 13.0

-- 
 (c) John Stockton, Surrey, UK.  ?@merlyn.demon.co.uk   Turnpike v6.05   MIME.
   Web  <http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
 Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
 Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web