Object.getPrototypeOf should return null when the parameter is Object.prototype

[normanzb]

according to test on latest chrome, firefox, opera, and safari at the moment, Object.getPrototypeOf should return null when the parameter is Object.prototype

[briancavalier]

Interesting! It makes sense, and I see that node (at least 0.10) returns null as well. I can't find any explicit mention of Object.prototype's prototype being null in the current ES5 spec, though. @normanzb do you know if it's in there, and maybe I am missing it, or maybe there is an addendum or a TC39 discussion that mentions it?

Thanks!

[normanzb]

I am now thinking maybe it is not because of getPrototypeOf() method, but because of the [[prototype]] of Object.prototype.

The es5 spec doesn't clearly specify what the [[prototype]] of Object.prototype should be but do clearly says that it shouldn't be Object.prototype itself:

Unless otherwise specified every built-in prototype object has the Object prototype object, which is the initial value of the expression Object.prototype (15.2.4), as the value of its [[Prototype]] internal property, except the Object prototype object itself

(i guess) also because of specification as of below, modern browser set [[prototype]] of Object.prototype to null:

All objects have an internal property called [[Prototype]]. The value of this property is either null or an object and is used for implementing inheritance. Whether or not a native object can have a host object as its [[Prototype]] depends on the implementation. Every [[Prototype]] chain must have finite length (that is, starting from any object, recursively accessing the [[Prototype]] internal property must eventually lead to a null value).

[briancavalier]

(i guess) also because of specification as of below, modern browser set [[prototype]] of Object.prototype to null:

Ah, yes, that is a good find. The "finite [[Prototype]] chain" coupled with "value...is either null or an object" makes it clear that an implementation setting [[Prototype]] of Object.prototype to null is allowed (and possibly encouraged).

So, yeah, I think you're right. Object.getPrototypeOf(Object.prototype) is just doing its job and returning the [[Prototype]] of Object.prototype, which, it just so happens has been set to null by many modern host envs.

It also means that callers can't actually depend on the value being null, since the spec doesn't actually say that it must be null. That's kind of unfortunate.

Given that, I think your original suggestion is still valid. IOW, poly can return null for Object.getPrototypeOf(Object.prototype), and be fully compliant with the spec.

@unscriptable what do you think?

[unscriptable]

Hey @normanzb! Can you change this pull request so that it targets the dev branch? Then I'll pull it in. -- John

[normanzb]

Pull request updated on #26

[briancavalier]

What the heck. I definitely did not just merge this. I got a notification in hipchat that it was merged by me, but I did no such thing.

[briancavalier]

Ok, I think we've (thanks @scothis) figured this out. It seems that when you merge one pull request, github checks the repo's entire pull request queue for other PR's whose HEAD commit is in the target branch, and considers them to be merged. IOW, it's algorithm is based on repository and pull request commit state, and not the actual clicking of the Merge button in the UI (or more likely some combination of those things).

Anyway, since this PR contains no commits now, and was originally created from poly/master, obviously the PR HEAD commit is in poly/master :)

Mystery solved.