•
•
•
•
What is DaniWeb IT Discussion Community?
You're currently browsing the JavaScript / DHTML / AJAX section within the Web Development category of DaniWeb, a massive community of 456,433 software developers, web developers, Internet marketers, and tech gurus who are all enthusiastic about making contacts, networking, and learning from each other. In fact, there are 2,641 IT professionals currently interacting right now! Registration is free, only takes a minute and lets you enjoy all of the interactive features of the site.
Please support our JavaScript / DHTML / AJAX advertiser: Lunarpages Web Hosting
Views: 5666 | Replies: 16
![]() |
•
•
Join Date: Jul 2006
Location: Deptford, London
Posts: 971
Reputation:
Rep Power: 5
Solved Threads: 48
Well, yeah. ( undefined == null ) only works via type coercion.
IMO, more useful ( and pleasant reading ) than either is to coerce straight to boolean;
But only because I'd rarely make a meaningful working distinction between ( or differently handle ) an object variable being null or being undefined.
IMO, more useful ( and pleasant reading ) than either is to coerce straight to boolean;
if( x ) {
// where x may be null, undefined, or an object
} Plato forgot the nullahedron..
> But only because I'd rarely make a meaningful working distinction between ( or differently
> handle ) an object variable being null or being undefined.
isn't acceptable. :-)
> handle ) an object variable being null or being undefined.
null is a valid value, undefined is *nothing*. Undefined has a special significance in the sense that attempting to retrieve value for a non-existent key from a Javascript object returns undefined . Simply put, the distinction is important when:if(x) {
// do something
} I don't accept change. I don't deserve to live.
Happiness corrupts people.
Failing to value the lives of others cheapens your own.
Happiness corrupts people.
Failing to value the lives of others cheapens your own.
•
•
Join Date: Jul 2006
Location: Deptford, London
Posts: 971
Reputation:
Rep Power: 5
Solved Threads: 48
Of course, there are sometimes occasions where the distinction is meaningful, but === undefined or === null aren't always the most useful, consider:
Can, of course use
Using a
javascript Syntax (Toggle Plain Text)
if( x !== undefined ) { x.something( ); //Possible error, if x happens to be null: //""null is null or not an object"" //or something along those lines }
if ( ( x !== undefined ) & ( x !== null ) ) , but it doesn't really gain very much over if( x ) .Using a
typeof test ( AND a non-null test ) is probably the most effective, in most places. Plato forgot the nullahedron..
> Can, of course use if ( ( x !== undefined ) & ( x !== null ) ) , but it doesn't really gain
> very much over if( x ) .
Err..no, it very much does since blank strings, the boolean value
Also it is much better to base your test of undefined on
> very much over if( x ) .
Err..no, it very much does since blank strings, the boolean value
false and the integer 0 all evaluate to false. Consider:var person = {name: "sos", hostile: false, description: ''};
if(person["hostile"]) {
// Even though a mapping exists for they key 'hostile',
// the program flow doesn't enter this block.
}
if(person["description"]) {
// ditto here.
}Also it is much better to base your test of undefined on
typeof rather than comparison operator since comparison fails for non-existent variables. Consider the following two almost similar snippets. The first one doesn't work, the second one does:<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Script-Content-Type" content="text/javascript">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Test</title>
</head>
<body>
<script type="text/javascript">
alert(a === undefined);
</script>
</body>
</html><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Script-Content-Type" content="text/javascript">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Test</title>
</head>
<body>
<script type="text/javascript">
alert(typeof a === "undefined");
</script>
</body>
</html> I don't accept change. I don't deserve to live.
Happiness corrupts people.
Failing to value the lives of others cheapens your own.
Happiness corrupts people.
Failing to value the lives of others cheapens your own.
•
•
Join Date: Jul 2006
Location: Deptford, London
Posts: 971
Reputation:
Rep Power: 5
Solved Threads: 48
Ouch. I'd rather prefer to know if something is or isn't an object a string, a boolean, a null, etc. Hence typeof. Only testing ( x !== undefined ) and/or ( x !== null ) isn't atall helpful if I still have no idea what I can subsequently do with x.
The test I'd usually use is ( If I have absolutely no idea what x might be, and I'm hoping for an object for example ):
But, more often than not, I'd have a good idea what x is going to be, and would normally only ever use null as placeholder for things that I'm sure are only going to otherwise be objects, so, any tests can be more simply put ( assuming of course, that I control ALL of the functions involved ):
Otherwise, for the heterogenous collection.. I'd try and setup a convention for each value, or use a "real class" with a constructor/properties/etc.
If I'm expecting an object and I pull out a null ( or an undefined ) its probably, although not always, going to amount to the same recovery, e.g.:
But yeh, that only works if you keep the collection homogenous..
The test I'd usually use is ( If I have absolutely no idea what x might be, and I'm hoping for an object for example ):
javascript Syntax (Toggle Plain Text)
if( ( typeof x == "object " ) && x ) { //do whatever ( i.e. poke around in x .looking for the method/property I need ) [ the && x is needed because typeof null is "object" ] }
But, more often than not, I'd have a good idea what x is going to be, and would normally only ever use null as placeholder for things that I'm sure are only going to otherwise be objects, so, any tests can be more simply put ( assuming of course, that I control ALL of the functions involved ):
javascript Syntax (Toggle Plain Text)
var x = get_x_or_null( ); if( ! x ) { x = try_something_else_to_get_x_or_null( ); } //etc, etc.
Otherwise, for the heterogenous collection.. I'd try and setup a convention for each value, or use a "real class" with a constructor/properties/etc.
If I'm expecting an object and I pull out a null ( or an undefined ) its probably, although not always, going to amount to the same recovery, e.g.:
Javascript Syntax (Toggle Plain Text)
//I'm gonna keep _only_ object pointers to Whatever objects in here. var xx = Object( ); var a = xx[ "a" ]; if( ! a ) { //don't care if a is null or undefined, I need to do something with a Whatever. xx[ "a" ] = a = new Whatever( ); } a.do_something( );
But yeh, that only works if you keep the collection homogenous..
Plato forgot the nullahedron..
> But, more often than not, I'd have a good idea what x is going to be, and would normally
> only ever use null as placeholder for things that I'm sure are only going to otherwise be
> objects
Again fails if you end up explicitly constructing Boolean, String and Number objects since they suffer with the same drawbacks as their primitive counterparts.
> But yeh, that only works if you keep the collection homogenous..
...which almost never is the case with real world Javascript object literals. :-)
Anyways, the intent of my posts was not to nitpick at the code snippets which almost always work in normal cases, but to make it clear to the OP that dark corners do exist in the happy go lucky world of Javascript.
> only ever use null as placeholder for things that I'm sure are only going to otherwise be
> objects
Again fails if you end up explicitly constructing Boolean, String and Number objects since they suffer with the same drawbacks as their primitive counterparts.
> But yeh, that only works if you keep the collection homogenous..
...which almost never is the case with real world Javascript object literals. :-)
Anyways, the intent of my posts was not to nitpick at the code snippets which almost always work in normal cases, but to make it clear to the OP that dark corners do exist in the happy go lucky world of Javascript.
I don't accept change. I don't deserve to live.
Happiness corrupts people.
Failing to value the lives of others cheapens your own.
Happiness corrupts people.
Failing to value the lives of others cheapens your own.
•
•
Join Date: Jul 2006
Location: Deptford, London
Posts: 971
Reputation:
Rep Power: 5
Solved Threads: 48
•
•
•
•
Again fails if you end up explicitly constructing Boolean, String and Number objects since they suffer with the same drawbacks as their primitive counterparts.
That's something I never considered.
I don't consider coercion in and of itself a bad thing ( coercion between numeric types is a must ).. but.. implicitly having numbers converted to strings and back really is hellish, and conversion between objects and primitives in a language without pointers ( or some other equivelent layer of [de]referencing ) isn't nice either.
There's quite alot of dark corners, but most can be avoided, as long as you know what to expect.
Plato forgot the nullahedron..
![]() |
•
•
•
•
•
•
•
•
DaniWeb JavaScript / DHTML / AJAX Marketplace
•
•
•
•
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
- how to compare a string to null... (C++)
- Generic method parser / invoker (C#)
- Exception Data is Null. This method or property cannot be called on Null values. (VB.NET)
- Null Pointer? will this code work (C)
- Need Help to Print Doubly Linked List(DLL) (Java)
- Can you add pictures/sounds in a win32 console app? (C)
- Need help with DirectX code (C)
Other Threads in the JavaScript / DHTML / AJAX Forum
- Previous Thread: Toggle of content
- Next Thread: Pre-Fill Subject and Body fields in Web Outlook



Linear Mode