Si j'ai bien compris, chaque objet en JavaScript hérite du prototype Object.
On pourrait croire qu'il s'agit de couper les cheveux en quatre, mais il y a une différence entre JavaScript (le terme générique pour les implémentations ECMAScript) et ECMAScript (le langage utilisé pour les implémentations JavaScript). C'est l'ECMAScript qui définit un schéma d'héritage, et non le JavaScript, de sorte que seuls les objets ECMAScript natifs doivent mettre en œuvre ce schéma d'héritage.
Un programme JavaScript en cours d'exécution est constitué d'au moins les objets ECMAScript intégrés (Objet, Fonction, Nombre, etc.) et probablement de quelques objets natifs (par exemple, des fonctions). Il peut également contenir des objets hôtes (tels que des objets DOM dans un navigateur, ou d'autres objets dans d'autres environnements hôtes).
Alors que les objets intégrés et natifs doivent mettre en œuvre le schéma d'héritage défini dans la norme ECMA-262, les objets hôtes ne le font pas. Par conséquent, les objets d'un environnement JavaScript ne sont pas tous doit hériter de Objet.prototype . Par exemple, dans Internet Explorer, les objets hôtes sont implémentés en tant que ActiveX entraîneront des erreurs s'ils sont traités comme des objets natifs (d'où la raison pour laquelle les essayer..attraper est utilisé pour initialiser Microsoft XMLHttpRequest ). Certains objets DOM (comme les NodeLists dans Internet Explorer en mode quirks), s'ils sont passés aux méthodes Array, provoqueront des erreurs, les objets DOM dans Internet Explorer 8 et inférieur n'ont pas un schéma d'héritage de type ECMAScript, et ainsi de suite.
Il ne faut donc pas supposer que tous les objets d'un environnement JavaScript héritent de Object.prototype.
ce qui signifie que chaque objet en JavaScript a accès à la fonction hasOwnProperty par le biais de sa chaîne de prototypes.
Ce qui n'est pas vrai pour certains objets hôtes dans Internet Explorer en mode quirks (et Internet Explorer 8 et inférieur toujours) au moins.
Compte tenu de ce qui précède, il convient de se demander pourquoi un objet peut avoir son propre hasOwnProperty et l'opportunité d'appeler une autre méthode hasOwnProperty sans avoir testé au préalable si c'était une bonne idée ou non.
Je soupçonne que la raison de l'utilisation de Object.prototype.hasOwnProperty.call est que dans certains navigateurs, les objets hôtes n'ont pas d'icône hasOwnProperty en utilisant appelez et la méthode intégrée est une alternative. Cependant, le faire de manière générique ne semble pas être une bonne idée pour les raisons mentionnées ci-dessus.
En ce qui concerne les objets hôtes, le sur L'opérateur peut être utilisé pour tester les propriétés de manière générale, par ex.
var o = document.getElementsByTagName('foo');
// false in most browsers, throws an error in Internet Explorer 6, and probably 7 and 8
o.hasOwnProperty('bar');
// false in all browsers
('bar' in o);
// false (in all browsers? Do some throw errors?)
Object.prototype.hasOwnProperty.call(o, 'bar');
Une alternative (testée dans Internet Explorer 6 et autres) :
function ownProp(o, prop) {
if ('hasOwnProperty' in o) {
return o.hasOwnProperty(prop);
} else {
return Object.prototype.hasOwnProperty.call(o, prop);
}
}
De cette façon, vous n'appelez spécifiquement que la fonction intégrée hasOwnProperty lorsque l'objet ne l'a pas (hérité ou non).
Cependant, si un objet n'a pas d'objet de type hasOwnProperty il est probablement tout aussi approprié d'utiliser la méthode sur car l'objet n'a probablement pas de schéma d'héritage et toutes les propriétés sont sur l'objet (ce n'est qu'une supposition), par exemple l'opérateur sur est une façon courante (et apparemment réussie) de tester le support des propriétés par les objets DOM.
