Si je comprends bien, chaque objet en Javascript hérite du prototype Object
Cela peut sembler couper les cheveux, 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 ECMAScript qui définit un schéma d'héritage, et non javascript, donc seuls les objets ECMAScript natifs doivent implémenter ce schéma d'héritage.
Un programme javascript en cours d'exécution comprend au moins les objets ECMAScript intégrés (objet, fonction, nombre, etc.) et probablement certains objets natifs (par exemple des fonctions). Il peut également avoir 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 implémenter le schéma d'héritage défini dans ECMA-262, les objets hôtes ne le font pas. Par conséquent, tous les objets d'un environnement javascript ne doivent pas hériter d' Object.prototype . Par exemple, les objets hôte dans IE implémentés en tant qu'objets ActiveX généreront des erreurs s'ils sont traités comme des objets natifs (d'où la raison pour laquelle try..catch est utilisé pour initialiser les objets MS XMLHttpRequest). Certains objets DOM (comme NodeLists dans IE en mode quirks), s'ils sont passés aux méthodes Array, génèrent des erreurs, les objets DOM dans IE 8 et les versions antérieures n'ont pas de schéma d'héritage de type ECMAScript, etc.
Par conséquent, il ne faut pas supposer que tous les objets dans un environnement javascript héritent d'Object.prototype.
ce qui signifie que chaque objet en Javascript a accès à la fonction hasOwnProperty via sa chaîne de prototypes
Ce qui n'est pas vrai pour certains objets hôtes dans IE en mode quirks (et IE 8 et inférieur toujours) au moins.
Compte tenu de ce qui précède, il vaut la peine de se demander pourquoi un objet peut avoir sa propre méthode hasOwnProperty et l'opportunité d'appeler une autre méthode hasOwnProperty à la place sans tester au préalable si c'est une bonne idée ou non.
Éditer
Je soupçonne que la raison de l'utilisation Object.prototype.hasOwnProperty.call
est que dans certains navigateurs, les objets hôtes n'ont pas de méthode hasOwnProperty , l'utilisation de call 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, l' opérateur in peut être utilisé pour tester les propriétés en général, par exemple
var o = document.getElementsByTagName('foo');
// false in most browsers, throws an error in IE 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 IE6 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 le hasOwnProperty intégré que là où l'objet ne l'a pas (hérité ou autre).
Cependant, si un objet n'a pas de hasOwnProperty
méthode, il est probablement tout aussi approprié d'utiliser l' opérateur in 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 cependant qu'une hypothèse), par exemple le in est une manière courante (et apparemment réussie) de tester la prise en charge des objets DOM pour les propriétés.