[解決済み] なぜ myObj.hasOwnProperty(prop) の代わりに Object.prototype.hasOwnProperty.call(myObj, prop) を使用するのですか？

質問

私が正しく理解していれば、JavaScriptの各オブジェクトはObjectプロトタイプを継承しており、JavaScriptの各オブジェクトはそのプロトタイプチェーンを通じてhasOwnProperty関数にアクセスできることを意味します。

読みながら RequireJS のソースコードを読んでいたら、この関数に行き当たりました。

function hasProp(obj, prop) {
    return hasOwn.call(obj, prop);
}

hasOwn は Object.prototype.hasOwnProperty . この関数を次のように書くことに実用的な違いはあるのでしょうか？

function hasProp(obj, prop) {
    return obj.hasOwnProperty(prop);
}

そして、せっかくなので、なぜこの関数をまったく定義しないのでしょうか？それは、単にパフォーマンス向上のためのプロパティ アクセスのショートカットとローカル キャッシュの問題なのでしょうか、それとも、このメソッドを持たないオブジェクトで hasOwnProperty が使用される可能性があるケースを見逃しているのでしょうか？

どのように解決するのですか?

実用上、何か違いがあるのでしょうか？

ユーザは、JavaScriptオブジェクトを Object.create(null) を持つことになります。 null [[Prototype]] を持つことになり、そのため hasOwnProperty() を利用できません。このため、2つ目のフォームを使用すると、動作に失敗します。

また、より安全な参照先として Object.prototype.hasOwnProperty() (を参照する方が安全です（さらに短い）。

誰かがやったかもしれないと想像することができる...

var someObject = {
    hasOwnProperty: function(lol) {
        return true;
    }
};

を作ることになります。 hasProp(someObject) に委譲されるのではなく、オブジェクト上で直接そのメソッドを見つけ、それを呼び出すことになります）。 Object.prototype.hasOwnProperty ).

を上書きする可能性は低くなります。 Object.prototype.hasOwnProperty の参照を上書きする可能性は低くなります。

ついでながら、なぜこの関数をまったく定義しないのでしょうか？

上記を参照してください。

それは プロパティアクセスのショートカットとローカルキャッシュの問題です。 (わずかな) パフォーマンス向上のためのショートカットとプロパティ アクセスのローカル キャッシュの問題なのでしょうか...

それは より速く として、理論的には [[Prototype]] の連鎖をたどる必要がないため、理論的には早くなります。しかし、これは無視できる程度だと思いますし ではなく が実装の理由ではないでしょうか。

... あるいは、私は以下のようなケースを見逃しているのでしょうか？ hasOwnProperty がこのメソッドを持っていないオブジェクトに使われるようなケースを見逃していませんか？

hasOwnProperty() に存在する Object.prototype に存在しますが、オーバーライドすることができます。すべてのネイティブJavaScriptオブジェクト（ただし、ホストオブジェクトはこれに従うことが保証されていない。 RobG の詳細な説明を参照してください。 を参照してください）には Object.prototype の前にあるチェーン上の最後のオブジェクトとして null の前の連鎖の最後のオブジェクトとして扱われます (勿論 Object.create(null) ).