Prototipos nativos frente a $ .extension()

Question

En el trabajo, utilizamos jQuery. Poco después de que comenzamos a usarlo, vi que un par de desarrolladores estaban agregando funciones a un archivo jquery-extensions.js. En el interior, encontré un montón de métodos agregados a $ que básicamente equivalen a métodos estáticos en jQuery. He aquí algunos de ellos:

$.formatString(str, args) { 
    ... 
} 

$.objectToArray(obj) { 
    ... 
} 

Etc. Ninguno de ellos utilizan realmente nada que ver con jQuery. Esto me pareció extraño.

Eventualmente, necesitábamos una función en nuestra biblioteca para localizar las fechas. Mi solución fue crear:

Date.prototype.toLocaleDate = function() { 
    ... 
} 

Date.parseLocalDate = function() { 
    ... 
} 

Poco después de hacer esto, aparece un señor desarrollador que sube para pedirme lo que pienso que estoy haciendo. Él me dice que aquí, donde trabajo, no creamos prototipos porque son malvados. Las únicas razones que dio fue que son fundamentalmente características de un lenguaje deficiente porque "pueden ser objeto de abuso" y que es confuso ver prototipos (por ejemplo, cómo sé la nueva Fecha(). ToLocaleDate() es un prototipo y no es ECMAScript nativo) Al usar $.formatString(...) en lugar de "blah blah".formatString(...), estamos dejando en claro que cualquier cosa con $ no es parte de JavaScript nativo.

Esas razones parecer un poco tonto, pero me ofreció un compromiso para que no tenga que recordar si un método era un prototipo — prefijo del nombre de la función prototipo con $:

String.prototype.$format = function() { 
    ... 
} 

"blah blah".$format(...); 

que fue rápidamente descartada y ahora tengo que agregar estas funciones $ .myPrototypeAsAFauxStaticMethodOnjQuery() en todas partes.

¿Soy el único que piensa que esta práctica es estúpida?

Answer 1

El debate prototipos nativo es un poco cansado, hay puntos válidos en ambos lados, voy a tratar de resumir en la esperanza que podría ser útil para ver la cuadro grande.

contra No es necesario extender los prototipos nativos. Tienes todo lo que necesitas
pro La biblioteca estándar JS es escasa al extremo. Las matrices y cadenas carecen de muchas características vitales.

contra Use funciones o sus propios "espacios de nombres".
pro Los métodos como foo.trim() están mucho más en el espíritu del lenguaje que las funciones como org.blah.trim(foo). Todo es un objeto en javascript y que así sea.

contra Los objetos nativos JS están "reservados" para los diseñadores de idiomas. Nuestros métodos pueden anular accidentalmente los complementos recién agregados.
pro Abrir objetos es una gran característica y sería una tontería no usarlo. Una nueva versión de Javascript no es algo que sucede todos los días y las adiciones al estándar son bien conocidas de antemano.

contra Extender prototipos nativos es confuso, porque no hay distinción entre nuestros métodos nativos.
pro La biblioteca estándar JS es pequeña y está bien documentada. Se supone que los desarrolladores de javascript debemos conocer los nombres de los métodos nativos.

contra La extensión de prototipos puede provocar conflictos en el espacio de nombres.
pro Sí, pero esto puede suceder con funciones globales o objetos globales bien conocidos (como $) también.

contra Los métodos personalizados son enumerables.
pro Sí, pero hay hasOwnProperty al rescate. Envuélvalo en su propia función de enumerador y deje de usar raw for..in bucles con objetos.

(no es una respuesta real, por lo tanto, CW)

Answer 2

1. Los títulos para personas mayores a menudo están sobrevalorados.
2. Hay muchas personas que no entienden la herencia prototípica.
3. Aunque es legal extender el prototipo de objetos JavaScript nativos, no lo haga. Usted corre el riesgo de chocar con los marcos.
4. No tiene sentido secuestrar $ para las funciones de utilidad no jQuery. ¿Por qué no usar el espacio de nombre propio de la empresa? Si tiene que ser conciso, utilice $$ etc.

Answer 3

creo que no es estúpida !, pero es más hermoso para usar prototipo !, Pero, de nuevo, que se preocupa por la belleza? Su código finalmente dará miedo y will suck, pero si está bien documentado y consistente ¡nunca tendrá que pensar en estos problemas!