Clean up language in the object section.

Author: michaeltwofish

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/
 

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*.
 

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).
 

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/