return format.replace(/[d,?.?]+/, fnum);

.equals(o) {
return this.valueOf() === o.valueOf();
}

usually does the trick. However, it also turns out that JavaScript does apply all methods attached to the Number.prototype to any Number variable automatically. So you can do:

var i = 1;
i.format(’$0,0′);

but you can’t do

1.toFixed(’$0,0′);

As such, there is little reason to force cast to the Number Object.

While the truthiness aspect is true…with numbers I’d argue it’s more correct to code with equality operators, that are explicit in their meaning. “if(numLiteral === 0)” checks specifically whether or not the numLiteral is 0. However, the same statement with numObject, would be false, as the === operator doesn’t do the conversion from a number object to a number literal. The == operator will be true (assuming both numbers are equal to zero).

I generally avoid using Number Objects, mostly out of personal preference. However, one potential advantage they do have, is you can add attributes to Number Objects, but not Number literals. So numberObject.x = 2 would be okay…numberLiteral.x = 2, probably won’t get a syntax error, but numberLiteral.x will still be undefined. I haven’t ever had to add an attribute to a number object, but that doesn’t mean it couldn’t be useful.

I’m not a fan of extending native objects, but to each his own. Otherwise, good read.