'undefined' is a flaw in JavaScript
-
I now consider that the way that 'undefined' is implemented in JavaScript represents a flaw in the language. IMHO, everything (at least variables) in JavaScript are Objects, but I just realize that variables that are 'undefined', are not. It is unfortunate that constant values are not objects. It would be a nice to have. For instance, it is possible to do:
var a=1; a.toString();
and not
1.toString();
. With regards to undefined, it isn't possible to do neither
var a=undefined; a.toString();
nor
undefined.toString();
Hence it breaks several principles that Programming Languages should respect. If 'undefined' were an object, it could act as a Null Object, and all variables would automatically have a Null Object. It would then suffice to do something like:
Object.prototype.isMyObject=false;
MyObject.prototype.isMyObject=true;and then one could always write:
if(anyvar.isMyObject){ /*...*/ }
without falling in the undefined issue. However, I do understand that today many developers may partly rely on 'undefined' resulting in an exception to detect flaws in their programs. Therefore a new option might be added to JavaScript, much like "strict" in order to indicate that 'undefined' should act as a Null Object. But that might not even be necessary, as the exception could simply be thrown only when trying to get a missing member of the object, as in:
undefined.missingVariable
or
undefined.missingFunction()
. So in conclusion: having undefined variables behave as Objects would make the JavaScript language "more complete", and having constants (like the number 1) behave as Objects would take it even one step further. If those impacting the definition of the language could consider that, I would be quite happy about it.
-- Mario DW
-
I now consider that the way that 'undefined' is implemented in JavaScript represents a flaw in the language. IMHO, everything (at least variables) in JavaScript are Objects, but I just realize that variables that are 'undefined', are not. It is unfortunate that constant values are not objects. It would be a nice to have. For instance, it is possible to do:
var a=1; a.toString();
and not
1.toString();
. With regards to undefined, it isn't possible to do neither
var a=undefined; a.toString();
nor
undefined.toString();
Hence it breaks several principles that Programming Languages should respect. If 'undefined' were an object, it could act as a Null Object, and all variables would automatically have a Null Object. It would then suffice to do something like:
Object.prototype.isMyObject=false;
MyObject.prototype.isMyObject=true;and then one could always write:
if(anyvar.isMyObject){ /*...*/ }
without falling in the undefined issue. However, I do understand that today many developers may partly rely on 'undefined' resulting in an exception to detect flaws in their programs. Therefore a new option might be added to JavaScript, much like "strict" in order to indicate that 'undefined' should act as a Null Object. But that might not even be necessary, as the exception could simply be thrown only when trying to get a missing member of the object, as in:
undefined.missingVariable
or
undefined.missingFunction()
. So in conclusion: having undefined variables behave as Objects would make the JavaScript language "more complete", and having constants (like the number 1) behave as Objects would take it even one step further. If those impacting the definition of the language could consider that, I would be quite happy about it.
-- Mario DW
First of all - numbers and strings are not object in JavaScript, but just like undefined are 'primitive types'...The difference is that for string and number there is a wrapping object but not for undefined...You are welcome to create one (and resolve your problem undefined not being an object)!!! As for the
1.toString()part...It is not hing more than a parsing problem...In JavaScript there is only number, no int or float or other sub-types... So1.tis a syntax problem only - try1.0.toString()and see how it works (so constant values are objects, when it suits the parser/compiler)...Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
First of all - numbers and strings are not object in JavaScript, but just like undefined are 'primitive types'...The difference is that for string and number there is a wrapping object but not for undefined...You are welcome to create one (and resolve your problem undefined not being an object)!!! As for the
1.toString()part...It is not hing more than a parsing problem...In JavaScript there is only number, no int or float or other sub-types... So1.tis a syntax problem only - try1.0.toString()and see how it works (so constant values are objects, when it suits the parser/compiler)...Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
Peter, thanks for the interesting feedback. Thanks to your keywords I found this: ECMAScript Language Specification paragraph 7.1.13 on page number 43 indicates that 'undefined' and 'null' are not converted into an object. So yes, you are right that numbers and strings are not objects, but they are "coerced" (if that is the right word) into objects temporarily when the context kind of asks for it. It would be nice that that also applies to 'undefined' and 'null'. I do not see a way to define the "automatic" and "temporary" conversion to an object myself, just the way it happens for strings, numbers and booleans. If you have a way, I'll take it ;-).
-
Peter, thanks for the interesting feedback. Thanks to your keywords I found this: ECMAScript Language Specification paragraph 7.1.13 on page number 43 indicates that 'undefined' and 'null' are not converted into an object. So yes, you are right that numbers and strings are not objects, but they are "coerced" (if that is the right word) into objects temporarily when the context kind of asks for it. It would be nice that that also applies to 'undefined' and 'null'. I do not see a way to define the "automatic" and "temporary" conversion to an object myself, just the way it happens for strings, numbers and booleans. If you have a way, I'll take it ;-).
Think about how JavaScript enclosed inside DOM... When you write var n = new Number();, Number is a shortcut for window.Number. Same goes for undefined (it is a property of the window object, but not number or string)...The problem is that since ECMA 5 it is read-only and for that can not be overridden... So there is no way to 'fake' and automatic boxing of undefined in the context of window, but you can create an object that does it and create your own closure (scope) that will define undefined as that object... If you ever saw an opening line like this...
(function (window, document) {
// we refer to window and document normally
})(window, document);Didn't you asked yourself why those parameters, especially undefined? So it is because before ECMA 5 undefined was mutable... Now if you do not bring undefined in (to protect yourself) into your closure, you can define an the name 'undefined' with other value and start using it inside your closure...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
Think about how JavaScript enclosed inside DOM... When you write var n = new Number();, Number is a shortcut for window.Number. Same goes for undefined (it is a property of the window object, but not number or string)...The problem is that since ECMA 5 it is read-only and for that can not be overridden... So there is no way to 'fake' and automatic boxing of undefined in the context of window, but you can create an object that does it and create your own closure (scope) that will define undefined as that object... If you ever saw an opening line like this...
(function (window, document) {
// we refer to window and document normally
})(window, document);Didn't you asked yourself why those parameters, especially undefined? So it is because before ECMA 5 undefined was mutable... Now if you do not bring undefined in (to protect yourself) into your closure, you can define an the name 'undefined' with other value and start using it inside your closure...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
I've tried the following, and 'undefined' does not seem 'fakable' as you say. A local variable can assume another value, but the value of that variable is of course not assumes by undefined variables.
(function(window){
var undefined='a';
console.log(undefined); // prints 'a'
console.log(window); // prints 'undefined' -> window is defined as 'undefined'
console.log(a); // throws error (a is undefined).
})(undefined)The following code also changes the local value of 'undefined', but not the 'undefined' of 'a' itself.
(function(undefined){
console.log(undefined); // prints 'a'
console.log(a); // throws error (a is undefined).
})('a') -
I've tried the following, and 'undefined' does not seem 'fakable' as you say. A local variable can assume another value, but the value of that variable is of course not assumes by undefined variables.
(function(window){
var undefined='a';
console.log(undefined); // prints 'a'
console.log(window); // prints 'undefined' -> window is defined as 'undefined'
console.log(a); // throws error (a is undefined).
})(undefined)The following code also changes the local value of 'undefined', but not the 'undefined' of 'a' itself.
(function(undefined){
console.log(undefined); // prints 'a'
console.log(a); // throws error (a is undefined).
})('a')It just shows how fundamentally 'undefined' is deep in the JavaScript engine... As you (we) can not change it from the outside, you may talk to the committee...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
First of all - numbers and strings are not object in JavaScript, but just like undefined are 'primitive types'...The difference is that for string and number there is a wrapping object but not for undefined...You are welcome to create one (and resolve your problem undefined not being an object)!!! As for the
1.toString()part...It is not hing more than a parsing problem...In JavaScript there is only number, no int or float or other sub-types... So1.tis a syntax problem only - try1.0.toString()and see how it works (so constant values are objects, when it suits the parser/compiler)...Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
Instead of 1.toString () we can use (1).toString().It will work fine by the java script perser.
