Chapter 4. Coercion
Now that we much more fully understand JavaScript’s types and values, we turn our attention to a very controversial topic: coercion.
As we mentioned in Chapter 1, the debates over whether coercion is a useful feature or a flaw in the design of the language (or somewhere in between!) have raged since day one. If you’ve read other popular books on JS, you know that the overwhelmingly prevalent message out there is that coercion is magical, evil, confusing, and just downright a bad idea.
In the same overall spirit of this series, rather than running away from coercion because everyone else does, or because you get bitten by some quirk, I think you should run toward that which you don’t understand and seek to get it more fully.
Our goal is to fully explore the pros and cons (yes, there are pros!) of coercion, so that you can make an informed decision on its appropriateness in your program.
Converting Values
Converting a value from one type to another is often called “type casting,” when done explicitly, and “coercion” when done implicitly (forced by the rules of how a value is used).
Note
It may not be obvious, but JavaScript coercions always result
in one of the scalar primitive (see Chapter 2) values, like string
,
number
, or boolean
. There is no coercion that results in a complex
value like object
or function
. Chapter 3 covers “boxing,” which
wraps scalar primitive values in their object
counterparts, but this
is not really coercion in an accurate sense.