Solución:
¿Hay alguna diferencia práctica? [between my examples]?
El usuario puede tener un objeto JavaScript creado con Object.create(null), que tendrá un null [[Prototype]] cadena, y por lo tanto no tendrá hasOwnProperty() disponible en él. El uso de su segundo formulario no funcionaría por este motivo.
También es una referencia más segura a Object.prototype.hasOwnProperty() (y también más corto).
Puedes imaginar que alguien pudo haber hecho …
var someObject = {
hasOwnProperty: function(lol) {
return true;
}
};
Lo que haría un hasProp(someObject) fallaría si hubiera sido implementado como su segundo ejemplo (encontraría ese método directamente en el objeto e invocaría eso, en lugar de ser delegado a Object.prototype.hasOwnProperty).
Pero es menos probable que alguien haya anulado el Object.prototype.hasOwnProperty referencia.
Y ya que estamos en eso, ¿por qué definimos esta función en absoluto?
Véase más arriba.
¿Es solo una cuestión de accesos directos y almacenamiento en caché local del acceso a la propiedad para obtener (leves) ganancias de rendimiento …
Puede hacerlo mas rapido en teoría, como el [[Prototype]] no es necesario seguir la cadena, pero sospecho que esto es insignificante y no la razón de la implementación es por qué lo es.
… o me falta algún caso en el que
hasOwnPropertypodría usarse en objetos que no tienen este método?
hasOwnProperty() existe en Object.prototype, pero puede anularse. Todos los objetos JavaScript nativos (pero no se garantiza que los objetos host sigan esto, consulte la explicación detallada de RobG) Object.prototype como su último objeto en la cadena antes null (excepto, por supuesto, para el objeto devuelto por Object.create(null)).
Si entiendo correctamente, todos y cada uno de los objetos en JavaScript heredan del prototipo de Objeto
Puede parecer que se parten los pelos, pero hay una diferencia entre JavaScript (el término genérico para las implementaciones de ECMAScript) y ECMAScript (el lenguaje utilizado para las implementaciones de JavaScript). Es ECMAScript el que define un esquema de herencia, no JavaScript, por lo que solo los objetos ECMAScript nativos deben implementar ese esquema de herencia.
Un programa JavaScript en ejecución consta al menos de los objetos ECMAScript integrados (Objeto, Función, Número, etc.) y probablemente algunos objetos nativos (por ejemplo, funciones). También puede tener algunos objetos de host (como objetos DOM en un navegador u otros objetos en otros entornos de host).
Si bien los objetos nativos e integrados deben implementar el esquema de herencia definido en ECMA-262, los objetos host no lo hacen. Por lo tanto, no todos los objetos en un entorno JavaScript debe heredar de Object.prototype. Por ejemplo, los objetos de host en Internet Explorer implementados como objetos ActiveX arrojarán errores si se tratan como objetos nativos (de ahí la razón trata de atraparlo se utiliza para inicializar objetos XMLHttpRequest de Microsoft). Algunos objetos DOM (como NodeLists en Internet Explorer en modo peculiar) si se pasan a métodos Array arrojarán errores, los objetos DOM en Internet Explorer 8 y versiones inferiores no tienen un esquema de herencia similar a ECMAScript, etc.
Por lo tanto, no se debe asumir que todos los objetos en un entorno JavaScript heredan de Object.prototype.
lo que significa que todos y cada uno de los objetos en JavaScript tiene acceso a la función hasOwnProperty a través de su cadena de prototipos
Lo cual no es cierto para ciertos objetos de host en Internet Explorer en modo peculiar (e Internet Explorer 8 y versiones inferiores siempre) al menos.
Dado lo anterior, vale la pena reflexionar sobre por qué un objeto puede tener su propio hasOwnProperty método y la conveniencia de llamar a algún otro hasOwnProperty en su lugar, sin probar primero si es una buena idea o no.
Sospecho que la razón para usar Object.prototype.hasOwnProperty.call es que en algunos navegadores, los objetos de host no tienen un hasOwnProperty método, usando llama y el método incorporado es una alternativa. Sin embargo, hacerlo de forma genérica no parece una buena idea por las razones mencionadas anteriormente.
En lo que respecta a los objetos de acogida, en El operador se puede utilizar para probar las propiedades en general, p. ej.
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');
Una alternativa (probada en Internet Explorer 6 y otros):
function ownProp(o, prop) {
if ('hasOwnProperty' in o) {
return o.hasOwnProperty(prop);
} else {
return Object.prototype.hasOwnProperty.call(o, prop);
}
}
De esa manera, solo llamarás específicamente a la función integrada hasOwnProperty donde el objeto no lo tiene (heredado o no).
Sin embargo, si un objeto no tiene un hasOwnProperty método, probablemente sea igual de adecuado para usar el en operador ya que el objeto probablemente no tiene un esquema de herencia y todas las propiedades están en el objeto (eso es solo una suposición), por ejemplo, el en El operador es una forma común (y aparentemente exitosa) de probar el soporte de objetos DOM para propiedades.
JavaScript no protege el nombre de la propiedad hasOwnProperty
Si existe la posibilidad de que un objeto tenga una propiedad con este nombre, es necesario utilizar una propiedad hasOwnProperty externa para obtener resultados correctos:
Puede copiar y pegar los siguientes fragmentos de código en la consola de su navegador para comprender mejor
var foo = {
hasOwnProperty: function() {
return false;
},
bar: 'I belong to foo'
};
Siempre devuelve falso
foo.hasOwnProperty('bar'); // false
Use hasOwnProperty de otro objeto y llámelo con esta establecido para foo
({}).hasOwnProperty.call(foo, 'bar'); // true
También es posible utilizar la propiedad hasOwnProperty desde el Objeto prototipo para este propósito
Object.prototype.hasOwnProperty.call(foo, 'bar'); // true