15

I understand that the hasOwnProperty method in JavaScript exists to identify properties only of the current type, but there is something in the prototype chain here that is confusing to me.

Let us imagine that I define a type called Bob, and assign two child functions to my Bob type in two different ways:

function Bob()
{
    this.name="Bob"; 
    this.sayGoodbye=function()
    {
        console.log("goodbye");   
    }
}

Bob.prototype.sayHello= function()
{
    console.log("hello");   
}

Now aside from having access to closure scope in the case of sayGoodbye, it seems to me that both functions belonging to the Bob class should be more or less equal. However, when I look for them with hasOwnProperty they are not the same as far as JavaScript is concerned:

var myBob = new Bob();
console.log( myBob.name ); // Bob, obviously 
console.log( myBob.hasOwnProperty("sayHello"));  // false
console.log( myBob.hasOwnProperty("sayGoodbye")); // true
console.log( "sayHello" in myBob ); // true

What is happening here in terms of scope? I could not create an instance of the Bob type without having the sayHello() and sayGoodbye() properties connected to it, so why is the prototype method a second class citizen as far as hasOwnProperty is concerned? Is Bob.prototype a type that exists somehow independently of the Bob type, from which Bob inherits everything?

glenatron
  • 11,018
  • 13
  • 64
  • 112
  • 3
    `hasOwnProperty` exists only to check the object itself for properties, it explicitly does not walk up the prototype chain, as that would defeat the purpose. – adeneo Mar 17 '14 at 01:03
  • What I was looking for clarification on is why properties on a type's own prototype would not be identified by `hasOwnProperty`. – glenatron Mar 17 '14 at 01:10
  • Property access has nothing to do with scope, it is entirely different. – RobG Mar 17 '14 at 01:11
  • 1
    @glenatron - The real answer is because that's the way `hasOwnProperty()` was designed. It only checks properties directly on the object, not anywhere in the prototype chain. I can see a rationale for a different function that tells you if the property is on the object or in it's own prototype, but that is not what `.hasOwnProperty()` was written to do. You could write such a function. – jfriend00 Mar 17 '14 at 01:13
  • @jfriend00— *typeof* will suite for most cases, but if traversing the `[[Prototype]]` chain is required, then it is dependent on one of [`getPrototyeOf`](http://ecma-international.org/ecma-262/5.1/#sec-15.2.3.2), `__proto__` or that the *constructor* property and *constructor.prototoype* are accurate. But I don't see that there's much benefit to that beyond that provided by *typeof*. – RobG Mar 17 '14 at 01:23
  • @RobG - it depends upon what the OP is really trying to do. My guess is that there's probably a better way to solve their issue entirely if they explained what the actual problem is. – jfriend00 Mar 17 '14 at 01:27
  • @jfriend00 my exact goal here is to improve my understanding of how JavaScript's scope and inheritance stuff works, which still manages to be a regular source of surprises to me after all these years. – glenatron Mar 17 '14 at 01:31
  • 2
    @glenatron—step one is recognising that scope has nothing to do with property access. The first relates to resolution of variables in a [lexical environment](http://ecma-international.org/ecma-262/5.1/#sec-10.2), the other relates to [property name](http://ecma-international.org/ecma-262/5.1/#sec-4.3.30) resolution on an object and its `[[Prototype]]` chain. – RobG Mar 17 '14 at 01:51
  • @glenatron - The reason I asked about the actual problem is that I've encountered many reasons to use `.hasOwnProperty()` the way it works and many reasons to see if the object has a property in any way, but never encountered a reason to use the function you're asking about in real code. – jfriend00 Mar 17 '14 at 02:51
  • @jfriend00 The structure of the actual case isn't too different to my example- I have classes that have a set of properties, some of which are 'own' properties others are on the class prototype ( but no higher up the chain ) and as both seem to me ( with a background in more traditional object oriented languages ) to be part of the same class definition, I wasn't sure why I could only treat some as properties of an instance of the type. As it is I am just using `in` to do the same job, which is fine here. Trying to understand rather than just fix the problem. – glenatron Mar 17 '14 at 15:42

2 Answers2

14

I think you're confusing a few concepts here. Let's take this quote from the MDN:

Every object descended from Object inherits the hasOwnProperty method. This method can be used to determine whether an object has the specified property as a direct property of that object; unlike the in operator, this method does not check down the object's prototype chain.

So that's the key here. When you use new JavaScript will assign a brand new object to this and return it, that's what an instance is. Any property declared inside the constructor is an own property. Properties declared on the prototype are not, since they are shared with other instances of the same object.

And a prototype is also an Object, for example:

Bob.prototype.hasOwnProperty("sayHello"); //=> true

myBob.constructor.prototype.hasOwnProperty("sayHello"); //=> true
elclanrs
  • 92,861
  • 21
  • 134
  • 171
  • 1
    Does that mean I could instantiate a new `Bob.prototype` that would have access to all the shared properties of the `Bob` type but not its constructor? Assuming I was sufficiently drunk that it seemed like a good idea. – glenatron Mar 17 '14 at 01:13
  • 1
    Yes, that how you do inheritance, `NewObject.prototype = Object.create(Bob.prototype)` – elclanrs Mar 17 '14 at 01:15
  • @glenatron - `Bob.prototype` already exists as an object. You don't have to instantiate one to read what's in it. – jfriend00 Mar 17 '14 at 01:15
  • @elclanrs that's not how _I_ do inheritance, but it is very probably how I _should_ do inheritance. Normally I'd just say `James.prototype = new Bob()` – glenatron Mar 17 '14 at 01:29
  • Well, yes that's how you'd do it in old browsers, but it's a bit hacky in a way... Check the polyfill here https://developer.mozilla.org/en- – elclanrs Mar 17 '14 at 01:52
4

I understand that the hasOwnProperty method in JavaScript exists to identify properties only of the current type

That is not correct. hasOwnProperty identifies own properties of an object, that is, properties of the object itself. It does not consider inherited properties on an object's [[Prototype]] chain.

e.g.

var foo = {name: 'foo'};

// Check for an own property
foo.hasOwnProperty('name'); // true

The object foo also inherits a toString method from Object.prototype, but it's not an "own" property:

typeof foo.toString             // function
foo.hasOwnProperty('toString'); // false
RobG
  • 142,382
  • 31
  • 172
  • 209
  • I got that regarding the longer inheritance chain. The specific confusion I had was where one had a property declared through the `foo.prototype.name` specifically, so the property only exists on type `foo` and it's children. Although the definition of _own_ properties explains where I went wrong, I don't think it would be illogical if all properties uniquely belonging to `foo` and its children were considered properties of `foo` rather than only those within the function declaration. – glenatron Mar 17 '14 at 15:50