Passing wrong object to hasOwnProperty method.

doc/en/object/hasownproperty.md

@@ -5,26 +5,26 @@ 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
-> property might very well exist, but its value just happens to be set to 
+> property might very well exist, but its value just happens to be set to
 > `undefined`.
 
-`hasOwnProperty` is the only thing in JavaScript which deals with properties and 
+`hasOwnProperty` is the only thing in JavaScript which deals with properties and
 does **not** traverse the prototype chain.
 
     // Poisoning Object.prototype
-    Object.prototype.bar = 1; 
+    Object.prototype.bar = 1;
     var foo = {goo: undefined};
-    
+
     foo.bar; // 1
     'bar' in foo; // true
 
     foo.hasOwnProperty('bar'); // false
     foo.hasOwnProperty('goo'); // true
 
-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 
-somewhere on its 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
+somewhere on its prototype chain.
 
 ### `hasOwnProperty` as a Property
 
@@ -45,7 +45,7 @@ necessary to use an *external* `hasOwnProperty` to get correct results.
     ({}).hasOwnProperty.call(foo, 'bar'); // true
 
     // It's also possible to use the hasOwnProperty property from the Object property for this purpose
-    Object.prototype.hasOwnProperty.call(obj, 'bar'); // true
+    Object.prototype.hasOwnProperty.call(foo, 'bar'); // true
 
 
 ### In Conclusion

doc/en/object/prototype.md

@@ -1,23 +1,23 @@
 ## The Prototype
 
-JavaScript does not feature a classical inheritance model; instead, it uses a 
-*prototypal* one. 
+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 
+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 a
 prototypal model, while the other way around is a far more difficult task.
 
 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. 
+models.
 
 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 
-> will affect the prototype of the other as well, which in most cases is not the 
+> sharing the **same** prototype. Therefore, changes to either object's prototype
+> will affect the prototype of the other as well, which in most cases is not the
 > desired effect.
 
     function Foo() {
@@ -36,26 +36,26 @@ chains*.
     // Make sure to list Bar as the actual constructor
     Bar.prototype.constructor = Bar;
 
-    var test = new Bar() // create a new bar instance
+    var test = new Bar(); // create a new bar instance
 
     // The resulting prototype chain
     test [instance of Bar]
-        Bar.prototype [instance of Foo] 
+        Bar.prototype [instance of Foo]
             { foo: 'Hello World' }
             Foo.prototype
                 { method: ... }
                 Object.prototype
                     { toString: ... /* etc. */ }
 
 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 
+`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
-Bar()` does **not** create a new `Foo` instance, but reuses the one assigned to 
+Bar()` does **not** create a new `Foo` instance, but reuses the one assigned to
 its prototype; thus, all `Bar` instances will share the **same** `value` property.
 
-> **Note:** Do **not** use `Bar.prototype = Foo`, since it will not point to 
-> the prototype of `Foo` but rather to the function object `Foo`. So the 
+> **Note:** Do **not** use `Bar.prototype = Foo`, since it will not point to
+> the prototype of `Foo` but rather to the function object `Foo`. So the
 > prototype chain will go over `Function.prototype` and not `Foo.prototype`;
 > therefore, `method` will not be on the prototype chain.
 
@@ -71,7 +71,7 @@ hasn't found the specified property, it will return the value
 ### The Prototype Property
 
 While the prototype property is used by the language to build the prototype
-chains, it is still possible to assign **any** given value to it. However, 
+chains, it is still possible to assign **any** given value to it. However,
 primitives will simply get ignored when assigned as a prototype.
 
     function Foo() {}
@@ -85,22 +85,22 @@ creation of prototype chains.
 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. 
+will always traverse the full prototype chain.
 
-Also, when [iterating](#object.forinloop) over the properties of an object 
+Also, when [iterating](#object.forinloop) over the properties of an object
 **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 popular frameworks such as [Prototype][2], there is still no good 
+This technique is called [monkey patching][1] and breaks *encapsulation*. While
+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 
-the features of newer JavaScript engines; for example, 
+The **only** good reason for extending a built-in prototype is to backport
+the features of newer JavaScript engines; for example,
 [`Array.forEach`][3].
 
 ### In Conclusion