types+grammar: more tweaks, ch4 discussion of types controversy

types & grammar/ch1.md

@@ -17,13 +17,13 @@ In other words, if both the engine and the developer treat value `42` (the numbe
 
 That's by no means a perfect definition. But it's good enough for this discussion. And it's consistent with how JS describes itself.
 
-# Type to Type
+# A Type By Any Other Name...
 
 Beyond academic definition disagreements, why does it matter if JavaScript has *types* or not?
 
 Having a proper understanding of each *type* and its intrinsic behavior is absolutely essential to understanding how to properly and accurately convert values to different types (See Coercion, Chapter 4). Nearly every JS program ever written will need to handle value coercion in some shape or form, so it's important you do so responsibly and with confidence.
 
-If you have the `number` value `42`, but you want to treat it like a `string`, such as pulling out the `"2"` as a character, you obviously must first convert (coerce) the value from `number` to `string`.
+If you have the `number` value `42`, but you want to treat it like a `string`, such as pulling out the `"2"` as a character in position `1`, you obviously must first convert (coerce) the value from `number` to `string`.
 
 That seems simple enough.
 

types & grammar/ch4.md

@@ -1,6 +1,14 @@
 # You Don't Know JS: Types & Grammar
 # 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.
+
+Our goal here 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, not just following the crowd hype.
+
+## 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).
 
 Another way these terms are often distinguished is: "type casting" (or "type conversion") occur in statically typed languages at compile time, while "type coercion" is a run-time conversion for dynamically typed languages.
@@ -31,4 +39,6 @@ If you know exactly what `+ ""` is doing and you're intentionally doing that to
 
 But we're conducting this discussion of "explicit" vs "implicit" based on the likely opinions of an *average, reasonably informed, but not expert or JS specification devotee*. To whatever extent you do or do not find yourself fitting neatly in that bucket, you will need to adjust your perspective on our observations here accordingly.
 
-Just remember: it's often rare that we write our code and we're the only ones who ever read it. Even if you're an expert on all the ins and outs of JS, consider how a less-experienced teammate of yours will *feel* when they read your code. Will it be "explicit" or "implicit" to them in the same way as it is for you?
+Just remember: it's often rare that we write our code and are the only ones who ever read it. Even if you're an expert on all the ins and outs of JS, consider how a less-experienced teammate of yours will *feel* when they read your code. Will it be "explicit" or "implicit" to them in the same way as it is for you?
+
+## Explicit Coercion

types & grammar/toc.md

@@ -4,7 +4,7 @@
 
 * Preface
 * Chapter 1: Types
-	* Type to Type
+	* A Type By Any Other Name...
 	* Primitives
 	* Values As Types
 * Chapter 2: Values
@@ -17,5 +17,6 @@
 	* Boxing Wrappers
 	* Natives As Constructors
 * Chapter 4: Coercion
+	* Converting Values
 * Appendix A: Thank You's!