From 295df974ba9949a96e2bf3f1456a7fd72b5d9928 Mon Sep 17 00:00:00 2001 From: Kyle Simpson Date: Mon, 5 Jan 2015 02:12:00 -0600 Subject: [PATCH] for consistency, replacing 'Summary' with 'Review' to match first two titles --- async & performance/apA.md | 2 +- async & performance/apB.md | 2 +- async & performance/ch1.md | 2 +- async & performance/ch2.md | 2 +- async & performance/ch3.md | 2 +- async & performance/ch4.md | 2 +- async & performance/ch5.md | 2 +- async & performance/ch6.md | 2 +- es6 & beyond/ch1.md | 2 +- types & grammar/apA.md | 2 +- types & grammar/ch1.md | 2 +- types & grammar/ch2.md | 2 +- types & grammar/ch3.md | 2 +- types & grammar/ch4.md | 2 +- types & grammar/ch5.md | 2 +- up & going/ch1.md | 2 +- up & going/ch2.md | 2 +- up & going/ch3.md | 2 +- 18 files changed, 18 insertions(+), 18 deletions(-) diff --git a/async & performance/apA.md b/async & performance/apA.md index 9eafa36cf..273aa641d 100644 --- a/async & performance/apA.md +++ b/async & performance/apA.md @@ -815,7 +815,7 @@ foo( 8, 9 ) There's a lot more awesome that `runner(..)` is capable of, but we'll come back to that in the next appendix. -## Summary +## Review *asynquence* is a simple abstraction -- a sequence is a series of (async) steps -- on top of promises, aimed at making working with various asynchronous patterns much easier, without any compromise in capability. diff --git a/async & performance/apB.md b/async & performance/apB.md index 7d86130ac..e5df38487 100644 --- a/async & performance/apB.md +++ b/async & performance/apB.md @@ -822,7 +822,7 @@ If there are any remaining values in the `ch` channel at the end of the goroutin **Note:** See many more examples of using *asynquence*-flavored CSP here (https://gist.github.com/getify/e0d04f1f5aa24b1947ae). -## Summary +## Review Promises and generators provide the foundational building blocks upon which we can build much more sophisticated and capable asynchrony. diff --git a/async & performance/ch1.md b/async & performance/ch1.md index ea8ce851f..a55cd283c 100644 --- a/async & performance/ch1.md +++ b/async & performance/ch1.md @@ -879,7 +879,7 @@ While JS semantics thankfully protect us from the *observable* nightmares that c Compiler statement reordering is almost a micro-metaphor for concurrency and interaction. As a general concept, such awareness can help you understand async JS code flow issues better. -## Summary +## Review A JavaScript program is (practically) always broken up into two or more chunks, where the first chunk runs *now* and the next chunk runs *later*, in response to an event. Even though the program is executed chunk-by-chunk, all of them share the same access to the program scope and state, so each modification to state is made on top of the previous state. diff --git a/async & performance/ch2.md b/async & performance/ch2.md index 127f04149..110c1a6ef 100644 --- a/async & performance/ch2.md +++ b/async & performance/ch2.md @@ -588,7 +588,7 @@ That's just the story, over and over again, with callbacks. They can do pretty m You might find yourself wishing for built-in APIs or other language mechanics to address these issues. Finally ES6 has arrived on the scene with some great answers, so keep reading! -## Summary +## Review Callbacks are the fundamental unit of asynchrony in JS. But they're not enough for the evolving landscape of async programming as JS matures. diff --git a/async & performance/ch3.md b/async & performance/ch3.md index f8cbe9178..5783fa3d4 100644 --- a/async & performance/ch3.md +++ b/async & performance/ch3.md @@ -2114,7 +2114,7 @@ Instead, you should default to using them across the code base, and then profile Promises are a little slower, but you're getting a lot of trustability, non-Zalgo predictability, and composability built-in, in exchange. So maybe the limitation is not actually their performance, but your lack of perception of their benefits? -## Summary +## Review Promises are awesome. Use them. They solve all the *inversion of control* issues that plague us with callbacks-only code. diff --git a/async & performance/ch4.md b/async & performance/ch4.md index d5bf4a9b5..88155aebb 100644 --- a/async & performance/ch4.md +++ b/async & performance/ch4.md @@ -2294,7 +2294,7 @@ This is more work than just using a `Promise` API polyfill for pre-ES6 promises, Once you get hooked on generators, you'll never want to go back to the hell of async spaghetti callbacks! -## Summary +## Review Generators are a new ES6 function type which does not run-to-completion like normal functions. Instead, the generator can be paused in mid-completion (entirely preserving its state), and it can later be resumed from where it left off. diff --git a/async & performance/ch5.md b/async & performance/ch5.md index 49163656d..b9f69c006 100644 --- a/async & performance/ch5.md +++ b/async & performance/ch5.md @@ -390,7 +390,7 @@ The first call to `fooASM(..)` is what sets up our asm.js module with its `heap` Obviously, the nature of restrictions that make asm.js code so optimizable reduces the use cases for such code significantly. asm.js won't necessarily be a general optimization set for any general JS program. Instead, it's intended to provide an optimized way of handling specialized tasks such as intensive math operations (like those used in graphics processing in games, for instance). -## Summary +## Review The first four chapters of this book are based on the premise that async coding patterns give you the ability to write more performant code, which is generally a very important improvement. But async behavior only gets you so far, because it's still fundamentally bound to a single event loop thread. diff --git a/async & performance/ch6.md b/async & performance/ch6.md index 363a020b4..32c9315e6 100644 --- a/async & performance/ch6.md +++ b/async & performance/ch6.md @@ -592,7 +592,7 @@ If the lack of TCO in the engine would just gracefully degrade to slower perform ES6 guarantees that from now on, JS developers will be able to rely on this optimization across all ES6+ compliant browsers. That's a win for JS performance! -## Summary +## Review Effectively benchmarking performance of a piece of code, especially to compare it to another option for that same code to see which approach is faster, requires careful attention to detail. diff --git a/es6 & beyond/ch1.md b/es6 & beyond/ch1.md index b8ba93019..61359087a 100644 --- a/es6 & beyond/ch1.md +++ b/es6 & beyond/ch1.md @@ -3,4 +3,4 @@ // TODO -## Summary +## Review diff --git a/types & grammar/apA.md b/types & grammar/apA.md index f97885d9a..d3c6ecc19 100644 --- a/types & grammar/apA.md +++ b/types & grammar/apA.md @@ -384,7 +384,7 @@ Examples of other limits known to exist: It's not very common at all to run into these limits, but you should be aware that limits can and do exist, and importantly that they vary between engines. -## Summary +## Review We know and can rely upon the fact that the JS language itself has one standard and is predictably implemented by all the modern browsers/engines. This is a very good thing! diff --git a/types & grammar/ch1.md b/types & grammar/ch1.md index 1eb4349e1..7fd7d5e8a 100644 --- a/types & grammar/ch1.md +++ b/types & grammar/ch1.md @@ -286,7 +286,7 @@ function doSomethingCool(FeatureXYZ) { There's lots of options when designing such functionality. No one pattern here is "correct" or "wrong" -- there are various tradeoffs to each approach. But overall, it's nice that the `typeof` undeclared safety guard gives us more options. -## Summary +## Review JavaScript has seven built-in *types*: `null`, `undefined`, `boolean`, `number`, `string`, `object`, `symbol`. They can be identified by the `typeof` operator. diff --git a/types & grammar/ch2.md b/types & grammar/ch2.md index 9dc336045..d4912423f 100644 --- a/types & grammar/ch2.md +++ b/types & grammar/ch2.md @@ -971,7 +971,7 @@ Instead of using the wrapper object `Number` in this way, it's probably much bet References are quite powerful, but sometimes they get in your way, and sometimes you need them where they don't exist. The only control you have over reference vs. value-copy behavior is the type of the value itself, so you must indirectly influence the assignment/passing behavior by which value types you choose to use. -## Summary +## Review In JavaScript, `array`s are simply numerically indexed collections of any value-type. `string`s are somewhat "`array`-like", but they have distinct behaviors and care must be taken if you want to treat them as `array`s. Numbers in JavaScript include both "integers" and floating-point values. diff --git a/types & grammar/ch3.md b/types & grammar/ch3.md index e331ce40f..5ade1e039 100644 --- a/types & grammar/ch3.md +++ b/types & grammar/ch3.md @@ -477,7 +477,7 @@ Also, be very careful not to use `Array.prototype` as a default value **that wil **Note:** While we're pointing out these native prototypes and some usefulness, be cautious of relying on them and even more wary of modifying them in anyway. See Appendix A "Native Prototypes" for more discussion. -## Summary +## Review JavaScript provides object wrappers around primitive values, known as natives (`String`, `Number`, `Boolean`, etc). These object wrappers give the values access to behaviors appropriate for each object sub-type (`String#trim()` and `Array#concat(..)`). diff --git a/types & grammar/ch4.md b/types & grammar/ch4.md index c5c8ecce3..c27601e22 100644 --- a/types & grammar/ch4.md +++ b/types & grammar/ch4.md @@ -1882,7 +1882,7 @@ a < b; // false -- string comparison! Number( a ) < Number( b ); // true -- number comparison! ``` -## Summary +## Review In this chapter, we turned our attention to how JavaScript type conversions happen, called **coercion**, which can be characterized as either *explicit* or *implicit*. diff --git a/types & grammar/ch5.md b/types & grammar/ch5.md index 3c68de953..b75d428d6 100644 --- a/types & grammar/ch5.md +++ b/types & grammar/ch5.md @@ -1341,7 +1341,7 @@ The way this snippet processes is that it passes through all the `case` clause m While this sort of round-about logic is clearly possible in JavaScript, there's almost no chance that it's going to make for reasonable or understandable code. Be very skeptical if you find yourself wanting to create such circular logic flow, and if you really do, make sure you include plenty of code comments to explain what you're up to! -## Summary +## Review JavaScript grammar has plenty of nuance that we as developers should spend a little more time paying closer attention to than we typically do. A little bit of effort goes a long way to solidifying your deeper knowledge of the language. diff --git a/up & going/ch1.md b/up & going/ch1.md index 387024042..885355143 100644 --- a/up & going/ch1.md +++ b/up & going/ch1.md @@ -417,7 +417,7 @@ if (amount > BANK_BALANCE) { How did you do? It wouldn't hurt to try it again now that you've seen my code. And play around with changing some of the constants to see how the program runs with different values. -## Summary +## Review Learning programming doesn't have to be a complex and involved process. There are just a few basic concepts you need to wrap your head around. These act like building blocks. To build a tall tower, you start first by putting block on top of block on top of block. The same goes with programming. diff --git a/up & going/ch2.md b/up & going/ch2.md index 4dad738ad..cdad570fe 100644 --- a/up & going/ch2.md +++ b/up & going/ch2.md @@ -715,7 +715,7 @@ The same goes with `console.log(..)`. Your browser provides such mechanisms and This book, and this whole book series, focuses on JavaScript the language. That's why you don't see any substantial coverage of these non-JavaScript JavaScript mechanisms. -## Summary +## Review The first step to learning JavaScript's flavor of programming is to get a basic understandng of its core mechanisms like values, types, function closures, `this`, and prototypes. diff --git a/up & going/ch3.md b/up & going/ch3.md index 6680244b2..74ad5e0bd 100644 --- a/up & going/ch3.md +++ b/up & going/ch3.md @@ -95,7 +95,7 @@ The latter part of the book turns attention to briefly glance at things which we The future for JavaScript is bright. Isn't it time we start learning it!? -## Summary +## Review The YDKJS series is dedicated to the proposition that all JS developers can and should learn all of the parts of this great language. No person's opinion, no framework's assumptions, no project's deadline, should be the excuse for why you never learn and deeply understand JavaScript.