What's the point of the Boolean object?

Question

I am reading through the Mozilla Manual on JavaScript, and I come to this point in my reading, Boolean object. I can\'t see a single use for them. What\'s their point? Why w

Answer 1

Going back to the specification (ECMA-262.pdf page 151), note that when Boolean is called as a function rather than as a constructor, it does type conversion. Thus:

var t = 5
  , f = 0

console.log(Boolean(t))  //Prints true
console.log(Boolean(f))  //Prints false

Of course, being a JavaScript object, you can use it as a prototype using the 'new' operator, as others have noted, but I don't see any reason for doing that.

Answer 2

Creating a new boolean object "basically" runs the bit of code in the statement and then from there returns the true boolean value.

From the same docs:

1 var b = new Boolean(false);
2 if (b) // this condition evaluates to true

https://developer.mozilla.org/en/JavaScript/Guide/Statements#if...else_Statement

Answer 3

From the documentation:

Do not confuse the primitive Boolean values true and false with the true and false values of the Boolean object. Any object whose value is not undefined , null, 0, NaN, or the empty string , including a Boolean object whose value is false, evaluates to true when passed to a conditional statement.

Imagine the following scenario:

if(SomeBoolean){...}

will be true in scenarios where SomeBoolean is a Boolean object.

Conversely:

if(false){...}

will always be false

Addendum for clarification.

var someString = new Boolean("MyNonEmptyString")
if(someString) //true
var otherString = new Boolean("")
if(otherString) //false

Answer 4

Because this is (somewhat sadly) how the language was defined -- I suspect it was originally for performance/optimization; note the case of assignment to a string property below. (Java works similarly, although Scala and Python largely reject this distinction).

Note that Boolean isn't the only "wrapper type". There are also String and Number, for instance.

Because of this there remains a number of quirks (the below could just as much apply to Boolean):

typeof("foo") // string
typeof(new String("foo")) // object
"foo" instanceof String // false
new String("foo") instanceof String // true

// result is undefined: a string is a primitive and silently "ate" the assignment
// this also makes it a much cheaper value as it's not a "real" object
x = "f"; x.bar = 42; x.bar

// result is 42: a String is a "real" object with real properties!
// however, this also means that it may have a good bit more overhead
x = new String("f"); x.bar = 42; x.bar

I know this didn't "answer" the question, but rather chucks some more wood on the fire ;-)

The only real "gotcha" otherwise from the above is that perhaps new Boolean(false) is a truth-y value.

Happy coding.

Answer 5

You can coerce a true or false from any value with return Boolean(something), but it's shorter to write return !!something, which forces a true or false as well.

Answer 6

I would have to side with most of the people here that there isn't much need for the Boolean object, but I do want to point out a couple of things.

An explicit comparison will still evaluate like a boolean:

var someBool = new Boolean(false);
if (someBool == false)
    alert('Got here'); //Alerts 'Got here'

Because of this, you could sort of extend it to a subclass and still be able to have the comparison work as above:

var classExtension = {
    toYN: function() {
        return this == false ? 'N' : 'Y';
    }
};

function getNewClass(val) {
    var newBool = new Boolean(val);
    jQuery.extend(newBool, classExtension);
    return newBool;
}

var newTest = getNewClass(false);
if (newTest)
    alert('It\'s alive');
if (newTest == false)
    alert('And still a bool');
alert(newTest.toYN());

This will alert 'It's alive', 'And still a bool' and 'N'. http://jsfiddle.net/fkJuk/

But again, would you ever really need this? Even if you did, it would probably be better just to have your own separate class with a boolean property that gets checked. In the end, it's probably here for consistency; every primitive has direct constructor and prototype access in JavaScript.