Browse files

Merge in typo fixes by michaeltwofish

  • Loading branch information...
2 parents 71504f0 + 3dc251c commit 2a31216959857ddae7ee1d1e3c2ef460becdf067 @BonsaiDen committed Oct 17, 2012
View
12 doc/en/array/constructor.md
@@ -21,15 +21,15 @@ the actual indexes of the array will not be initialized.
arr[1]; // undefined
1 in arr; // false, the index was not set
-The behavior of being able to set the length of the array upfront only comes in
-handy in a few cases, like repeating a string, in which it avoids the use of a
-`for loop` code.
+Being able to set the length of the array in advance is only useful in a few
+cases, like repeating a string, in which it avoids the use of a `for loop`
+code.
new Array(count + 1).join(stringToRepeat);
### In Conclusion
-The use of the `Array` constructor should be avoided as much as possible.
-Literals are definitely preferred. They are shorter and have a clearer syntax;
-therefore, they also increase the readability of the code.
+The use of the `Array` constructor should be avoided. Literals are definitely
+preferred. They are shorter, have a clearer syntax, and increase code
+readability.
View
28 doc/en/core/delete.md
@@ -5,12 +5,11 @@ stuff in JavaScript which have a `DontDelete` attribute set.
### Global code and Function code
-When a variable or a function is defined in a global
-or a [function scope](#function.scopes) it is a property of either
-Activation object or Global object. Such properties have a set of attributes,
-one of these is `DontDelete`. Variable and function declarations in global
-and function code always create properties with `DontDelete`, therefore
-cannot be deleted.
+When a variable or a function is defined in a global or a [function
+scope](#function.scopes) it is a property of either the Activation object or
+the Global object. Such properties have a set of attributes, one of which is
+`DontDelete`. Variable and function declarations in global and function code
+always create properties with `DontDelete`, and therefore cannot be deleted.
// global variable:
var a = 1; // DontDelete is set
@@ -29,8 +28,7 @@ cannot be deleted.
### Explicit properties
-There are things which can be deleted normally: these are explicitly set
-properties.
+Explicitly set properties can be deleted normally.
// explicitly set property:
var obj = {x: 1};
@@ -40,8 +38,8 @@ properties.
obj.x; // undefined
obj.y; // undefined
-In the example above `obj.x` and `obj.y` can be deleted because they have no
-`DontDelete` atribute. That's why an example below works too.
+In the example above, `obj.x` and `obj.y` can be deleted because they have no
+`DontDelete` atribute. That's why the example below works too.
// this works fine, except for IE:
var GLOBAL_OBJECT = this;
@@ -58,7 +56,7 @@ IE (at least 6-8) has some bugs, so the code above doesn't work.
### Function arguments and built-ins
-Functions' normal arguments, [`arguments` object](#function.arguments)
+Functions' normal arguments, [`arguments` objects](#function.arguments)
and built-in properties also have `DontDelete` set.
// function arguments and properties:
@@ -78,10 +76,10 @@ and built-in properties also have `DontDelete` set.
### Host objects
-Behaviour of `delete` operator can be unpredictable for hosted objects. Due to
-specification, host objects are allowed to implement any kind of behavior.
+The behaviour of `delete` operator can be unpredictable for hosted objects. Due
+to the specification, host objects are allowed to implement any kind of behavior.
### In conclusion
-`delete` operator often has an unexpected behaviour and can be safely used
-only for dealing with explicitly set properties on normal objects.
+The `delete` operator often has unexpected behaviour and can only be safely
+used to delete explicitly set properties on normal objects.
View
18 doc/en/core/eval.md
@@ -12,7 +12,7 @@ The `eval` function will execute a string of JavaScript code in the local scope.
foo; // 1
However, `eval` only executes in the local scope when it is being called
-**directly** *and* when the name of the called function is actually `eval`.
+directly *and* when the name of the called function is actually `eval`.
var foo = 1;
function test() {
@@ -24,8 +24,8 @@ However, `eval` only executes in the local scope when it is being called
test(); // 2
foo; // 3
-The use of `eval` should be avoided at **all costs**. 99.9% of its "uses" can be
-achieved **without** it.
+The use of `eval` should be avoided. 99.9% of its "uses" can be achieved
+**without** it.
### `eval` in Disguise
@@ -35,13 +35,13 @@ in the global scope since `eval` is not being called directly in that case.
### Security Issues
-`eval` also is a security problem. Because it executes **any** code given to it,
-it should **never** be used with strings of unknown or untrusted origins.
+`eval` also is a security problem, because it executes **any** code given to it.
+It should **never** be used with strings of unknown or untrusted origins.
### In Conclusion
-`eval` should never be used. Any code that makes use of it is to be questioned in
-its workings, performance and security. In case something requires `eval` in
-order to work, it should **not** be used in the first place.
-A *better design* should be used, that does not require the use of `eval`.
+`eval` should never be used. Any code that makes use of it should be questioned
+in its workings, performance and security. If something requires `eval` in
+order to work, it should **not** be used in the first place. A *better design*
+should be used, that does not require the use of `eval`.
View
12 doc/en/core/semicolon.md
@@ -84,7 +84,7 @@ Below is the result of the parser's "guessing" game.
})(window); //<- inserted
> **Note:** The JavaScript parser does not "correctly" handle return statements
-> which are followed by a new line, while this is not neccessarily the fault of
+> that are followed by a new line. While this is not neccessarily the fault of
> the automatic semicolon insertion, it can still be an unwanted side-effect.
The parser drastically changed the behavior of the code above. In certain cases,
@@ -106,9 +106,9 @@ the above will yield a `TypeError` stating that `undefined is not a function`.
### In Conclusion
-It is highly recommended to **never** omit semicolons; it is also advocated to
-keep braces on the same line with their corresponding statements and to never omit
-them for one single-line `if` / `else` statements. Both of these measures will
-not only improve the consistency of the code, but they will also prevent the
-JavaScript parser from changing its behavior.
+It is highly recommended to **never** omit semicolons. It is also recommended
+that braces be kept on the same line as their corresponding statements and to
+never omit them for single-line `if` / `else` statements. These measures will
+not only improve the consistency of the code, but they will also prevent the
+JavaScript parser from changing code behavior.
View
20 doc/en/core/undefined.md
@@ -1,7 +1,7 @@
## `undefined` and `null`
-JavaScript has two distinct values for `nothing`, the more useful of these two
-being `undefined`.
+JavaScript has two distinct values for nothing, `null` and `undefined`, with
+the latter being more useful.
### The Value `undefined`
@@ -16,14 +16,14 @@ overwritten.
> mode, but its name can still be shadowed by for example a function with the name
> `undefined`.
-Some examples for when the value `undefined` is returned:
+Here are some examples of when the value `undefined` is returned:
- Accessing the (unmodified) global variable `undefined`.
- - Accessing a declared *but not* yet initialized variable
+ - Accessing a declared *but not* yet initialized variable.
- Implicit returns of functions due to missing `return` statements.
- - `return` statements which do not explicitly return anything.
+ - `return` statements that do not explicitly return anything.
- Lookups of non-existent properties.
- - Function parameters which do not had any explicit value passed.
+ - Function parameters that do not have any explicit value passed.
- Anything that has been set to the value of `undefined`.
- Any expression in the form of `void(expression)`
@@ -36,14 +36,14 @@ Since the global variable `undefined` only holds a copy of the actual *value* of
Still, in order to compare something against the value of `undefined`, it is
necessary to retrieve the value of `undefined` first.
-In order to protect code against a possible overwritten `undefined` variable, a
-common technique used is to add an additional parameter to an
-[anonymous wrapper](#function.scopes) that gets no argument passed to it.
+To protect code against a possible overwritten `undefined` variable, a common
+technique used is to add an additional parameter to an [anonymous
+wrapper](#function.scopes) that gets no argument passed to it.
var undefined = 123;
(function(something, foo, undefined) {
// undefined in the local scope does
- // now again refer to the value
+ // now again refer to the value `undefined`
})('Hello World', 42);
View
9 doc/en/function/arguments.md
@@ -79,9 +79,9 @@ of the corresponding property on the `arguments` object, and the other way aroun
### Performance Myths and Truths
-The `arguments` object is always created with the only two exceptions being the
-cases where it is declared as a name inside of a function or one of its formal
-parameters. It does not matter whether it is used or not.
+The only time the `arguments` object is not created is where it is declared as
+a name inside of a function or one of its formal parameters. It does not matter
+whether it is used or not.
Both *getters* and *setters* are **always** created; thus, using it has nearly
no performance impact at all, especially not in real world code where there is
@@ -108,8 +108,7 @@ needs to know about both itself and its caller. This not only defeats possible
performance gains that would arise from inlining, but it also breaks encapsulation
because the function may now be dependent on a specific calling context.
-It is **highly recommended** to **never** make use of `arguments.callee` or any of
-its properties.
+Making use of `arguments.callee` or any of its properties is **highly discouraged**.
> **ES5 Note:** In strict mode, `arguments.callee` will throw a `TypeError` since
> its use has been deprecated.
View
4 doc/en/function/closures.md
@@ -27,7 +27,7 @@ were defined. Since the only scoping that JavaScript has is
Here, `Counter` returns **two** closures: the function `increment` as well as
the function `get`. Both of these functions keep a **reference** to the scope of
`Counter` and, therefore, always keep access to the `count` variable that was
-defined in that very scope.
+defined in that scope.
### Why Private Variables Work
@@ -47,7 +47,7 @@ override - the *global* variable `count`.
### Closures Inside Loops
One often made mistake is to use closures inside of loops, as if they were
-copying the value of the loops index variable.
+copying the value of the loop's index variable.
for(var i = 0; i < 10; i++) {
setTimeout(function() {
View
32 doc/en/function/constructors.md
@@ -25,7 +25,7 @@ The above calls `Foo` as constructor and sets the `prototype` of the newly
created object to `Foo.prototype`.
In case of an explicit `return` statement, the function returns the value
-specified that statement, **but only** if the return value is an `Object`.
+specified by that statement, but **only** if the return value is an `Object`.
function Bar() {
return 2;
@@ -72,24 +72,24 @@ explicitly return a value.
new Bar();
Bar();
-Both calls to `Bar` return the exact same thing, a newly create object which
-has a property called `method` on it, which is a
+Both calls to `Bar` return the same thing, a newly create object that
+has a property called `method`, which is a
[Closure](#function.closures).
-It is also to note that the call `new Bar()` does **not** affect the prototype
-of the returned object. While the prototype will be set on the newly created
-object, `Bar` never returns that new object.
+It should also be noted that the call `new Bar()` does **not** affect the
+prototype of the returned object. While the prototype will be set on the newly
+created object, `Bar` never returns that new object.
In the above example, there is no functional difference between using and
not using the `new` keyword.
### Creating New Objects via Factories
-An often made recommendation is to **not** use `new` because forgetting its use
-may lead to bugs.
+It is often recommended to **not** use `new` because forgetting its use may
+lead to bugs.
-In order to create new object, one should rather use a factory and construct a
+In order to create a new object, one should rather use a factory and construct a
new object inside of that factory.
function Foo() {
@@ -113,16 +113,16 @@ downsides.
1. It uses more memory since the created objects do **not** share the methods
on a prototype.
- 2. In order to inherit the factory needs to copy all the methods from another
+ 2. In order to inherit, the factory needs to copy all the methods from another
object or put that object on the prototype of the new object.
3. Dropping the prototype chain just because of a left out `new` keyword
- somehow goes against the spirit of the language.
+ is contrary to the spirit of the language.
### In Conclusion
-While omitting the `new` keyword might lead to bugs, it is certainly **not** a
-reason to drop the use of prototypes altogether. In the end it comes down to
-which solution is better suited for the needs of the application, it is
-especially important to choose a specific style of object creation **and stick**
-with it.
+While omitting the `new` keyword might lead to bugs, it is certainly **not** a
+reason to drop the use of prototypes altogether. In the end it comes down to
+which solution is better suited for the needs of the application. It is
+especially important to choose a specific style of object creation and use it
+**consistently**.
View
6 doc/en/function/general.md
@@ -8,9 +8,9 @@ an *anonymous function* as a callback to another, possibly an asynchronous funct
function foo() {}
-The above function gets [hoisted](#function.scopes) before the execution of the
-program starts; thus, it is available *everywhere* in the scope it was *defined*
-in, even if called before the actual definition in the source.
+The above function gets [hoisted](#function.scopes) before the execution of the
+program starts; thus, it is available *everywhere* in the scope it was
+*defined*, even if called before the actual definition in the source.
foo(); // Works because foo was created before this code runs
function foo() {}
View
28 doc/en/function/scopes.md
@@ -73,7 +73,7 @@ unless the *desired effect* is to affect the outer scope.
### Local Variables
The only source for local variables in JavaScript are
-[function](#function.general) parameters and variables that were declared via the
+[function](#function.general) parameters and variables declared via the
`var` statement.
// global scope
@@ -115,8 +115,8 @@ JavaScript **hoists** declarations. This means that both `var` statements and
}
}
-The above code gets transformed before any execution is started. JavaScript moves
-the `var` statements, as well as the `function` declarations to the top of the
+The above code gets transformed before execution starts. JavaScript moves
+the `var` statements, as well as `function` declarations, to the top of the
nearest surrounding scope.
// var statements got moved here
@@ -150,15 +150,15 @@ In the original code, although the `if` statement seemed to modify the *global
variable* `goo`, it actually modifies the *local variable* - after hoisting
has been applied.
-Without the knowledge about *hoisting*, the below code might seem to raise a
+Without knowledge of *hoisting*, one might suspect the code below would raise a
`ReferenceError`.
// check whether SomeImportantThing has been initialized
if (!SomeImportantThing) {
var SomeImportantThing = {};
}
-But of course, the above works due to the fact that the `var` statement is being
+But of course, this works due to the fact that the `var` statement is being
moved to the top of the *global scope*.
var SomeImportantThing;
@@ -176,10 +176,10 @@ All scopes in JavaScript, including the *global scope*, have the special name
[`this`](#function.this), defined in them, which refers to the *current object*.
Function scopes also have the name [`arguments`](#function.arguments), defined in
-them, which contains the arguments that were passed to a function.
+them, which contains the arguments that were passed to the function.
For example, when trying to access a variable named `foo` inside the scope of a
-function, JavaScript will lookup the name in the following order:
+function, JavaScript will look up the name in the following order:
1. In case there is a `var foo` statement in the current scope, use that.
2. If one of the function parameters is named `foo`, use that.
@@ -191,9 +191,9 @@ function, JavaScript will lookup the name in the following order:
### Namespaces
-A common problem of having only one global namespace is the likeliness of running
-into problems where variable names clash. In JavaScript, this problem can
-easily be avoided with the help of *anonymous wrappers*.
+A common problem associated with having only one global namespace is the
+likelihood of running into problems where variable names clash. In JavaScript,
+this problem can easily be avoided with the help of *anonymous wrappers*.
(function() {
// a self contained "namespace"
@@ -208,13 +208,13 @@ easily be avoided with the help of *anonymous wrappers*.
Unnamed functions are considered [expressions](#function.general); so in order to
being callable, they must first be evaluated.
- ( // evaluate the function inside the paranthesis
+ ( // evaluate the function inside the parentheses
function() {}
) // and return the function object
() // call the result of the evaluation
-There are other ways for evaluating and directly calling the function expression; which,
-while different in syntax, do behave the exact same way.
+There are other ways to evaluate and directly call the function expression
+which, while different in syntax, behave the same way.
// A few other styles for directly invoking the
!function(){}()
@@ -224,7 +224,7 @@ while different in syntax, do behave the exact same way.
### In Conclusion
-It is recommended to always use an *anonymous wrapper* for encapsulating code in
+It is recommended to always use an *anonymous wrapper* to encapsulate code in
its own namespace. This does not only protect code against name clashes, but it
also allows for better modularization of programs.
View
8 doc/en/function/this.md
@@ -1,7 +1,7 @@
## How `this` Works
JavaScript has a different concept of what the special name `this` refers to
-than most other programming languages do. There are exactly **five** different
+than most other programming languages. There are exactly **five** different
ways in which the value of `this` can be bound in the language.
### The Global Scope
@@ -55,7 +55,7 @@ inside of `foo` will be set to `bar`.
### Common Pitfalls
-While most of these cases make sense, the first one is to be considered another
+While most of these cases make sense, the first can be considered another
mis-design of the language because it **never** has any practical use.
Foo.method = function() {
@@ -69,7 +69,7 @@ A common misconception is that `this` inside of `test` refers to `Foo`; while in
fact, it **does not**.
In order to gain access to `Foo` from within `test`, it is necessary to create a
-local variable inside of `method` which refers to `Foo`.
+local variable inside of `method` that refers to `Foo`.
Foo.method = function() {
var that = this;
@@ -105,7 +105,7 @@ fact, it is what makes [prototypal inheritance](#object.prototype) work.
new Bar().method();
-When `method` gets called on a instance of `Bar`, `this` will now refer to that
+When `method` gets called on an instance of `Bar`, `this` will now refer to that
very instance.
View
18 doc/en/object/forinloop.md
@@ -1,6 +1,6 @@
## The `for in` Loop
-Just like the `in` operator, the `for in` loop also traverses the prototype
+Just like the `in` operator, the `for in` loop traverses the prototype
chain when iterating over the properties of an object.
> **Note:** The `for in` loop will **not** iterate over any properties that
@@ -17,10 +17,10 @@ chain when iterating over the properties of an object.
Since it is not possible to change the behavior of the `for in` loop itself, it
is necessary to filter out the unwanted properties inside the loop body;
-this is done by using the [`hasOwnProperty`](#object.hasownproperty) method of
+this is done using the [`hasOwnProperty`](#object.hasownproperty) method of
`Object.prototype`.
-> **Note:** Since the `for in` always traverses the complete prototype chain, it
+> **Note:** Since `for in` always traverses the complete prototype chain, it
> will get slower with each additional layer of inheritance added to an object.
### Using `hasOwnProperty` for Filtering
@@ -37,15 +37,15 @@ will **only** print out `moo`. When `hasOwnProperty` is left out, the code is
prone to errors in cases where the native prototypes - e.g. `Object.prototype` -
have been extended.
-One widely used framework which does this is [Prototype][1]. When this
-framework is included, `for in` loops that do not use `hasOwnProperty` are
-guaranteed to break.
+One widely used framework that extends `Object.prototype` is [Prototype][1].
+When this framework is included, `for in` loops that do not use
+`hasOwnProperty` are guaranteed to break.
### In Conclusion
-It is recommended to **always** use `hasOwnProperty`. Never should any
-assumptions be made about the environment the code is running in, or whether the
-native prototypes have been extended or not.
+It is recommended to **always** use `hasOwnProperty`. Assumptions should never
+be made about the environment the code is running in, or whether the native
+prototypes have been extended or not.
[1]: http://www.prototypejs.org/
View
16 doc/en/object/general.md
@@ -16,25 +16,25 @@ notation* on a number as a floating point literal.
2.toString(); // raises SyntaxError
-There are a couple of workarounds which can be used in order make number
-literals act as objects too.
+There are a couple of workarounds that can be used to make number literals act
+as objects too.
2..toString(); // the second point is correctly recognized
2 .toString(); // note the space left to the dot
(2).toString(); // 2 is evaluated first
### Objects as a Data Type
-Objects in JavaScript can also be used as a [*Hashmap*][1]; they mainly consist
+Objects in JavaScript can also be used as [*Hashmaps*][1]; they mainly consist
of named properties mapping to values.
Using an object literal - `{}` notation - it is possible to create a
plain object. This new object [inherits](#object.prototype) from `Object.prototype` and
-has no [own properties](#object.hasownproperty) defined on it.
+does not have [own properties](#object.hasownproperty) defined.
var foo = {}; // a new empty object
- // a new object with a property called 'test' with value 12
+ // a new object with a 'test' property with value 12
var bar = {test: 12};
### Accessing Properties
@@ -52,13 +52,13 @@ notation or the square bracket notation.
foo.1234; // SyntaxError
foo['1234']; // works
-Both notations are identical in their workings, with the only difference being that
-the square bracket notation allows for dynamic setting of properties, as well as
+The notations work almost identically, with the only difference being that the
+square bracket notation allows for dynamic setting of properties and
the use of property names that would otherwise lead to a syntax error.
### Deleting Properties
-The only way to actually remove a property from an object is to use the `delete`
+The only way to remove a property from an object is to use the `delete`
operator; setting the property to `undefined` or `null` only removes the
*value* associated with the property, but not the *key*.
View
18 doc/en/object/hasownproperty.md
@@ -1,7 +1,7 @@
## `hasOwnProperty`
-In order to check whether a object has a property defined on *itself* and **not**
-somewhere on its [prototype chain](#object.prototype), it is necessary to use the
+To check whether an object has a property defined on *itself* and not somewhere
+on its [prototype chain](#object.prototype), it is necessary to use the
`hasOwnProperty` method which all objects inherit from `Object.prototype`.
> **Note:** It is **not** enough to check whether a property is `undefined`. The
@@ -23,14 +23,14 @@ does **not** traverse the prototype chain.
Only `hasOwnProperty` will give the correct and expected result; this is
essential when iterating over the properties of any object. There is **no** other
-way to exclude properties that are not defined on the object *itself*, but
+way to exclude properties that are not defined on the object itself, but
somewhere on its prototype chain.
### `hasOwnProperty` as a Property
-JavaScript does **not** protect the property name `hasOwnProperty`; thus, if the
+JavaScript does not protect the property name `hasOwnProperty`; thus, if the
possibility exists that an object might have a property with this name, it is
-necessary to use an *external* `hasOwnProperty` in order to get correct results.
+necessary to use an *external* `hasOwnProperty` to get correct results.
var foo = {
hasOwnProperty: function() {
@@ -44,14 +44,14 @@ necessary to use an *external* `hasOwnProperty` in order to get correct results.
// Use another Object's hasOwnProperty and call it with 'this' set to foo
({}).hasOwnProperty.call(foo, 'bar'); // true
- // It's also possible use the hasOwnProperty property from the Object property for this purpose
+ // It's also possible to use the hasOwnProperty property from the Object property for this purpose
Object.prototype.hasOwnProperty.call(obj, 'bar'); // true
### In Conclusion
-When checking for the existence of a property on a object, `hasOwnProperty` is
-the **only** method of doing so. It is also recommended to make `hasOwnProperty`
-part of **every** [`for in` loop](#object.forinloop); this will avoid errors from
+Using `hasOwnProperty` is the **only** reliable method to check for the
+existence of a property on an object. It is recommended that `hasOwnProperty`
+is used in **every** [`for in` loop](#object.forinloop) to avoid errors from
extended native [prototypes](#object.prototype).
View
42 doc/en/object/prototype.md
@@ -4,16 +4,16 @@ JavaScript does not feature a classical inheritance model; instead, it uses a
*prototypal* one.
While this is often considered to be one of JavaScript's weaknesses, the
-prototypal inheritance model is in fact more powerful than the classic model.
-It is, for example, fairly trivial to build a classic model on top of it, while the
-other way around is a far more difficult task.
+prototypal inheritance model is in fact more powerful than the classic model.
+It is, for example, fairly trivial to build a classic model on top of a
+prototypal model, while the other way around is a far more difficult task.
-Due to the fact that JavaScript is basically the only widely used language that
-features prototypal inheritance, it takes some time to adjust to the
-differences between the two models.
+JavaScript is the only widely used language that features prototypal
+inheritance, so it can take time to adjust to the differences between the two
+models.
-The first major difference is that inheritance in JavaScript is done by using so
-called *prototype chains*.
+The first major difference is that inheritance in JavaScript uses *prototype
+chains*.
> **Note:** Simply using `Bar.prototype = Foo.prototype` will result in both objects
> sharing the **same** prototype. Therefore, changes to either object's prototype
@@ -47,7 +47,7 @@ called *prototype chains*.
Object.prototype
{ toString: ... /* etc. */ }
-In the above, the object `test` will inherit from both `Bar.prototype` and
+In the code above, the object `test` will inherit from both `Bar.prototype` and
`Foo.prototype`; hence, it will have access to the function `method` that was
defined on `Foo`. It will also have access to the property `value` of the
**one** `Foo` instance that is its prototype. It is important to note that `new
@@ -64,7 +64,7 @@ its prototype; thus, all `Bar` instances will share the **same** `value` propert
When accessing the properties of an object, JavaScript will traverse the
prototype chain **upwards** until it finds a property with the requested name.
-When it reaches the top of the chain - namely `Object.prototype` - and still
+If it reaches the top of the chain - namely `Object.prototype` - and still
hasn't found the specified property, it will return the value
[undefined](#core.undefined) instead.
@@ -82,20 +82,21 @@ creation of prototype chains.
### Performance
-The lookup time for properties that are high up on the prototype chain can have a
-negative impact on performance critical sections of code. Additionally, trying to
-access non-existent properties will always traverse the full prototype chain.
+The lookup time for properties that are high up on the prototype chain can have
+a negative impact on performance, and this may be significant in code where
+performance is critical. Additionally, trying to access non-existent properties
+will always traverse the full prototype chain.
Also, when [iterating](#object.forinloop) over the properties of an object
-**every** property that is on the prototype chain will get enumerated.
+**every** property that is on the prototype chain will be enumerated.
### Extension of Native Prototypes
One mis-feature that is often used is to extend `Object.prototype` or one of the
other built in prototypes.
This technique is called [monkey patching][1] and breaks *encapsulation*. While
-used by widely spread frameworks such as [Prototype][2], there is still no good
+used by popular frameworks such as [Prototype][2], there is still no good
reason for cluttering built-in types with additional *non-standard* functionality.
The **only** good reason for extending a built-in prototype is to backport
@@ -104,11 +105,12 @@ the features of newer JavaScript engines; for example,
### In Conclusion
-It is a **must** to understand the prototypal inheritance model completely
-before writing complex code which makes use of it. Also, watch the length of
-the prototype chains and break them up if necessary to avoid possible
-performance issues. Further, the native prototypes should **never** be extended
-unless it is for the sake of compatibility with newer JavaScript features.
+It is **essential** to understand the prototypal inheritance model before
+writing complex code that makes use of it. Also, be aware of the length of the
+prototype chains in your code and break them up if necessary to avoid possible
+performance problems. Further, the native prototypes should **never** be
+extended unless it is for the sake of compatibility with newer JavaScript
+features.
[1]: http://en.wikipedia.org/wiki/Monkey_patch
[2]: http://prototypejs.org/
View
50 doc/en/other/timeouts.md
@@ -1,26 +1,26 @@
### `setTimeout` and `setInterval`
Since JavaScript is asynchronous, it is possible to schedule the execution of a
-function by using the `setTimeout` and `setInterval` functions.
+function using the `setTimeout` and `setInterval` functions.
> **Note:** Timeouts are **not** part of the ECMAScript Standard. They are
> implemented as part of the [DOM][1].
function foo() {}
var id = setTimeout(foo, 1000); // returns a Number > 0
-When `setTimeout` gets called, it will return the ID of the timeout and schedule
-`foo` to run in **approximately** one thousand milliseconds in the future.
-`foo` will then get executed exactly **once**.
+When `setTimeout` is called, it returns the ID of the timeout and schedule
+`foo` to run **approximately** one thousand milliseconds in the future.
+`foo` will then be executed **once**.
-Depending on the timer resolution of the JavaScript engine that is running the
-code, as well as the fact that JavaScript is single threaded and other code that
-gets executed might block the thread, it is by **no means** a safe bet that one
-will get the exact delay that was specified in the `setTimeout` call.
+Depending on the timer resolution of the JavaScript engine running the code, as
+well as the fact that JavaScript is single threaded and other code that gets
+executed might block the thread, it is by **no means** a safe bet that one will
+get the exact delay specified in the `setTimeout` call.
The function that was passed as the first parameter will get called by the
*global object*, which means that [`this`](#function.this) inside the called function
-refers to that very object.
+refers to the global object.
function Foo() {
this.value = 42;
@@ -34,7 +34,7 @@ refers to that very object.
> **Note:** As `setTimeout` takes a **function object** as its first parameter, an
-> often made mistake is to use `setTimeout(foo(), 1000)`, which will use the
+> common mistake is to use `setTimeout(foo(), 1000)`, which will use the
> **return value** of the call `foo` and **not** `foo`. This is, most of the time,
> a silent error, since when the function returns `undefined` `setTimeout` will
> **not** raise any error.
@@ -72,29 +72,31 @@ the function itself.
foo();
Not only does this encapsulate the `setTimeout` call, but it also prevents the
-stacking of calls and it gives additional control. `foo` itself can now decide
+stacking of calls and gives additional control. `foo` itself can now decide
whether it wants to run again or not.
### Manually Clearing Timeouts
Clearing timeouts and intervals works by passing the respective ID to
-`clearTimeout` or `clearInterval`, depending which `set` function was used in
-the first place.
+`clearTimeout` or `clearInterval`, depending on which `set` function was used
+in the first place.
var id = setTimeout(foo, 1000);
clearTimeout(id);
-### Clearing all timeouts
+### Clearing All Timeouts
-Because there is no built-in method for clearing all timeouts and/or intervals,
+As there is no built-in method for clearing all timeouts and/or intervals,
it is necessary to use brute force in order to achieve this functionality.
// clear "all" timeouts
for(var i = 1; i < 1000; i++) {
clearTimeout(i);
}
-But there might still be timeouts that are unaffected by this arbitrary number. Another way of doing this is to consider that the ID given to a timeout is incremented by one everytime you call `setTimeout`.
+But there might still be timeouts that are unaffected by this arbitrary number.
+Another way of doing this is to consider that the ID given to a timeout is
+incremented by one every time you call `setTimeout`.
// clear "all" timeouts
var biggestTimeoutId = window.setTimeout(function(){}, 1),
@@ -103,17 +105,19 @@ But there might still be timeouts that are unaffected by this arbitrary number.
clearTimeout(i);
}
-But even though this works on all main browsers nowadays, it isn't specified that the IDs should be ordered that way and it may change. Therefore, it is instead recommended to keep track of all the timeout IDs, so
-they can be cleared specifically.
+Even though this works on all major browsers today, it isn't specified that
+the IDs should be ordered that way and it may change. Therefore, it is instead
+recommended to keep track of all the timeout IDs, so they can be cleared
+specifically.
-### Hidden use of `eval`
+### Hidden Use of `eval`
`setTimeout` and `setInterval` can also take a string as their first parameter.
This feature should **never** be used because it internally makes use of `eval`.
> **Note:** Since the timeout functions are **not** specified by the ECMAScript
> standard, the exact workings when a string is passed to them might differ in
-> various JavaScript implementations. For example, Microsoft's JScript makes use of
+> various JavaScript implementations. For example, Microsoft's JScript uses
> the `Function` constructor in place of `eval`.
function foo() {
@@ -129,10 +133,10 @@ This feature should **never** be used because it internally makes use of `eval`.
bar();
Since `eval` is not getting called [directly](#core.eval) in this case, the string
-passed to `setTimeout` will get executed in the *global scope*; thus, it will
+passed to `setTimeout` will be executed in the *global scope*; thus, it will
not use the local variable `foo` from the scope of `bar`.
-It is further recommended to **not** use a string for passing arguments to the
+It is further recommended to **not** use a string to pass arguments to the
function that will get called by either of the timeout functions.
function foo(a, b, c) {}
@@ -151,7 +155,7 @@ function that will get called by either of the timeout functions.
### In Conclusion
-**Never** should a string be used as the parameter of `setTimeout` or
+A string should **never** be used as the parameter of `setTimeout` or
`setInterval`. It is a clear sign of **really** bad code, when arguments need
to be supplied to the function that gets called. An *anonymous function* should
be passed that then takes care of the actual call.
View
8 doc/en/types/casting.md
@@ -21,7 +21,7 @@ JavaScript is a *weakly typed* language, so it will apply *type coercion*
> (Base 8). Octal support for these has been **removed** in ECMAScript 5 strict
> mode.
-In order to avoid the above, use of the [strict equal operator](#types.equality)
+To avoid the issues above, use of the [strict equal operator](#types.equality)
is **highly** recommended. Although this avoids a lot of common pitfalls, there
are still many further issues that arise from JavaScript's weak typing system.
@@ -38,16 +38,16 @@ Using a built-in type like `Number` as a constructor will create a new `Number`
object, but leaving out the `new` keyword will make the `Number` function behave
like a converter.
-In addition, having literals or non-object values in there will result in even
-more type coercion.
+In addition, passing literals or non-object values will result in even more
+type coercion.
The best option is to cast to one of the three possible types **explicitly**.
### Casting to a String
'' + 10 === '10'; // true
-By prepending an empty string, a value can easily be casted to a string.
+By prepending an empty string, a value can easily be cast to a string.
### Casting to a Number
View
6 doc/en/types/equality.md
@@ -31,7 +31,7 @@ to another number.
The strict equality operator consists of **three** equal signs: `===`.
-It works exactly like the normal equality operator, except that strict equality
+It works like the normal equality operator, except that strict equality
operator does **not** perform type coercion between its operands.
"" === "0" // false
@@ -50,8 +50,8 @@ the operands are of different types.
### Comparing Objects
-While both `==` and `===` are stated as **equality** operators, they behave
-differently when at least one of their operands happens to be an `Object`.
+While both `==` and `===` are called **equality** operators, they behave
+differently when at least one of their operands is an `Object`.
{} === {}; // false
new String('foo') === 'foo'; // false
View
4 doc/en/types/instanceof.md
@@ -13,8 +13,8 @@ nearly as useless as the [typeof operator](#types.typeof).
new Bar() instanceof Bar; // true
new Bar() instanceof Foo; // true
- // This just sets Bar.prototype to the function object Foo
- // But not to an actual instance of Foo
+ // This just sets Bar.prototype to the function object Foo,
+ // but not to an actual instance of Foo
Bar.prototype = Foo;
new Bar() instanceof Foo; // false
View
17 doc/en/types/typeof.md
@@ -2,16 +2,16 @@
The `typeof` operator (together with
[`instanceof`](#types.instanceof)) is probably the biggest
-design flaw of JavaScript, as it is nearly **completely broken**.
+design flaw of JavaScript, as it is almost **completely broken**.
-Although `instanceof` still has its limited uses, `typeof` really has only one
+Although `instanceof` still has limited uses, `typeof` really has only one
practical use case, which does **not** happen to be checking the type of an
object.
-> **Note:** While `typeof` can also be called with a function like syntax
-> i.e. `typeof(obj)`, this is not a function call. The two parenthesis will
-> behave like normal and the return value will be used as the operand of the
-> `typeof` operator. There is **no** `typeof` function.
+> **Note:** While `typeof` can also be called with a function like syntax, i.e.
+> `typeof(obj)`, this is not a function call. The parentheses behave as normal
+> and the return value will be used as the operand of the `typeof` operator.
+> There is **no** `typeof` function.
### The JavaScript Type Table
@@ -79,9 +79,8 @@ referencing it would result in a `ReferenceError`. This is the only thing
In order to check the type of an object, it is highly recommended to use
`Object.prototype.toString` because this is the only reliable way of doing so.
As shown in the above type table, some return values of `typeof` are not defined
-in the specification; thus, they can differ across various implementations.
+in the specification; thus, they can differ between implementations.
-Unless checking whether a variable is defined, `typeof` should be avoided at
-**all costs**.
+Unless checking whether a variable is defined, `typeof` should be avoided.

0 comments on commit 2a31216

Please sign in to comment.