Why is hasOwnProperty being invoked generically here?

Question

The following function is mentioned in Speaking Javascript: An In-Depth Guide for Programmers by Axel Rauschmayer:

function getDefiningObject(obj, p         


        

Answer 1

Because obj.hasOwnProperty would terribly fall if the object was defined like these:

var obj = { hasOwnProperty: 123 };

var obj = Object.create(null);

With {}.hasOwnProperty you get a reference to the desired function from Object.prototype, you don't need to worry about it being shadowed somewhere closer in the prototypical chain, or the object not inheriting from Object.prototype.

This is a design problem, because hasOwnProperty should have been a static method, but now it's too late to fix it. Another solution is implementing HasOwnProperty manually:

Object.getOwnPropertyDescriptor(obj, prop) !== undefined

Answer 2

If you want to execute Object.prototype.hasOwnProperty on an object, and you attempt to use obj.hasOwnProperty(prop) you're making some assumptions:

• The object has a key named "hasOwnProperty". This is easy to fail if you create objects using Object.create(null).
• The object has a function at obj.hasOwnProperty. This is easy to fail if the object has a key that has been added named "hasOwnProperty". You might think this is a rare case, but it's not uncommon to parse things such as query strings into objects, and query strings are user-supplied.

Using Object.prototype.hasOwnProperty.call(obj, prop) you're reasonably guaranteed to have the method you want called on the object that's being passed in as input.

For utility purposes it's quite common to see something along the lines of:

function has(obj, prop) {
  return Object.prototype.hasOwnProperty.call(obj, prop);
}

Answer 3

Often, developers will use call on a built-in type to ensure that they are getting the correct native behavior of a method and not some overridden behavior.

It is a protective measure that we really shouldn't have to use, but because Objects are so malleable in JavaScript, it guarantees we get the behavior we desire.

Imagine if someone (who, intentionally or accidentally) created an object like this:

function SuperObject(){
   this.foo = function(){
     // Something here
   };

   this.hasOwnProperty = 42;
}

And then, you came along (without having seen the implementation of the object) and wrote:

var mySuperObject = new SuperObject();
console.log("Does 'mySuperObject' instance have its own 'foo' property? " +
            mySuperObject.hasOwnProperty("foo"));

You'd get this:

function SuperObject(){
  this.foo = function(){
    // Something here
  };
    
  this.hasOwnProperty = 42;
}


var mySuperObject = new SuperObject();

// Safe way:
console.log("Does 'mySuperObject' instance have its own 'foo' property? " +
             {}.hasOwnProperty.call(mySuperObject, "foo"));

// Unsafe way (fails):
console.log("Does 'mySuperObject' instance have its own 'foo' property? " +
             mySuperObject.hasOwnProperty("foo"));

So, instead we get code like this:

// This creates a new "fresh" (and unaltered) object with "object literal"
// syntax that you know doesn't override "hasOwnProperty"
{}.hasOwnProperty.call(obj, propKey)

// This performs the same task, but uses the native prototype object
// of the built-in Object type that we also know hasn't been altered:
Object.prototype.hasOwnProperty.call(obj, propKey) 

It forces the hasOwnProperty to be looked up on the prototype chain of the native Object, while:

obj.hasOwnProperty(propKey)

relies on that property being available and correct on a particular instance of an object (obj).

Other popular examples of this are with the Array type:

// These work the same as the Object examples above, but just 
// do it for the Array type:
[].forEach.call(); // Array literal syntax
Array.prototype.forEach.call(); // Explicit array syntax