¿Por qué la biblioteca de cierre de Google no usa miembros privados reales?

He sido desarrollador de JavaScript por un tiempo, y siempre he pensado que la forma correcta de implementar miembros privados en JavaScript es usar la técnica descrita por Doug Crockford aquí: http://javascript.crockford.com/private.html.¿Por qué la biblioteca de cierre de Google no usa miembros privados reales?

No pensé que esta era una parte particularmente controvertida de la sabiduría de JavaScript, hasta que comencé a usar la biblioteca de Google Closure. Imagínense mi sorpresa ... la biblioteca no hace ningún esfuerzo por esconder información al estilo de Crockford. Todo lo que hacen es usar una convención de nomenclatura especial y anotar miembros "privados" en la documentación. Tengo el hábito de asumir que los chicos de Google suelen estar a la vanguardia de la calidad del software, así que ¿qué da? ¿Hay algún inconveniente en seguir el consejo del Sr. Crockford que no es obvio?

Fuente

2010-04-03 Derek Thurn

vea la discusión en los comentarios a http://stackoverflow.com/questions/1437712/how-to-override-private-variable-in-javascript/1438592#1438592 para mi opinión – Christoph

Hay muchos ejemplos de pseudo-privacidad en las bibliotecas de JavaScript de la secuencia principal. La biblioteca de JavaScript de Facebook Connect tiene la misma estructura.

La razón principal por la que los desarrolladores siguen esa ruta es por su rendimiento. Ocultar cosas en cierres puede ser más lento y usar más memoria. La ocultación de cierre también puede ser menos flexible, ya que la verdadera privacidad no puede llevarse entre archivos sin some clever hacks. La ocultación de clausura es más puramente conceptual, IMO, pero cuando el rendimiento es una preocupación, usar pseudo-privacidad es el camino a seguir.

La otra razón es que muchos programadores de Google tienen experiencia en Python, donde no hay nada privado y el prefijo de subrayado es el estándar de comunidad aceptado.

Fuente

2010-04-03 18:46:13 bcherry

Las variables que están en cierres privados son un dolor en el culo al depurar también: P. También existe la filosofía de que Javascript no es un verdadero lenguaje OO, y no 'nativamente' (a falta de una mejor palabra que se me ocurra) admite variables privadas. – Matt

Herramientas como Firebug proporcionan acceso a toda la cadena de alcance, para que pueda ver las variables "privadas". A veces adjunto un método llamado '.debug()' a los módulos con miembros privados, que simplemente desencadena una declaración 'debugger;' y abre el cierre para su inspección (esto es como golpear un punto de interrupción). – bcherry

También hay más en la notación JSDOC de lo que parece: cuando utiliza el compilador de cierre de google, esas etiquetas "@private" se analizan y se aplican. Si algún objeto externo intenta acceder a una de estas variables, se genera un error de compilación. De hecho, tienen una objeción filosófica al patrón de herencia general de Crockford: http://www.bolinfest.com/javascript/inheritance.php

Fuente

2011-09-10 17:13:43 Max

Su modelo de herencia que utiliza goog.inherit() y goog.base() simplemente copian miembros prototipo de la superclase a la subclase.

Puede ver que la función de azúcar de Doug Crockford hace lo mismo. Personalmente he enfrentado muchos problemas al heredar un miembro con privilegios (this.property).

Con ambos métodos de herencia, las variables privadas simplemente desaparecen a diferencia de C++ o Java, donde no tiene acceso a los miembros privados de la superclase, pero todavía se heredan. Esta debe ser la principal razón por la que prefieren este enfoque.

Fuente

2011-11-20 19:06:06

¿Por qué la biblioteca de cierre de Google no usa miembros privados reales?

Respuesta

Cuestiones relacionadas