¿Por qué XMLHttpRequest no parece seguir una convención de nomenclatura?


28

He estado trabajando con el objeto XMLHttpRequest en JavaScript recientemente, y no pude evitar notar que la carcasa de este nombre no tiene sentido. ¿Por qué 'XML' está todo en mayúsculas mientras que 'Http' no? ¡Ambas son siglas!

Seguramente tendría más sentido que el nombre sea uno de los siguientes:

  • XmlHttpRequest (PascalCase, práctica recomendada para nombres de clase en JavaScript)
  • xmlHttpRequest (camelCase, también común, aunque no para clases)
  • XMLHTTPRequest (mayúsculas para acrónimos, ¿rara vez se usa en programación?)

Estoy seguro de que debe haber alguna razón y odiaría pensar que ahora está escrito en piedra solo porque nadie cuestionó esto en ese momento. ¿Hay otra convención de nomenclatura que desconozco?


99
Nota al margen: Java tiene una inconsistencia de nomenclatura muy similar: el HttpURLConnection.
Joachim Sauer

66
Nota al margen # 2: Al menos esos están escritos correctamente, a diferencia del HTTP_REFERERencabezado ...
OnoSendai

3
Sospecho que esto cae en la categoría de "Algunos desarrolladores cometieron un error y ahora no podemos corregirlo", pero es probable que solo haya una persona en el mundo que conozca la respuesta real.
Martin Brown

1
Sin embargo, no se pregunta por qué tiene XML (o incluso HTTP) en el nombre en primer lugar.
Deja de dañar a Mónica el

Respuestas:


15

Curiosamente, Microsoft lo llamó por primera vez IXMLHTTPRequestcuando se agregó por primera vez a la biblioteca MSXML .

Fue Mozilla quien usó el nombre XMLHttpRequestcuando agregó el concepto a Gecko, implementando la idea de imitar la interfaz de MS. Desde entonces se ha convertido en el estándar de facto, vinculando todas las demás implementaciones a la decisión de Mozilla.

Tendría que hacer espeleología en el Mozilla Bugzilla para ver si puede encontrar algún razonamiento para el cambio de mayúsculas allí, pero sospecho que no se pensó mucho y las minúsculas de la ttpparte son accidentales.

Esto se ve corroborado por la falta de ortografía de la interfaz de Microsoft en la definición de interfaz nsIXMLHttpRequest (la primera revisión en el repositorio Merz de Mozilla) :

XMLHttpRequest de Mozilla se basa en el objeto IXMLHttpRequest de Microsoft. El objetivo ha sido hacer que la versión de Mozilla coincida lo más posible con la versión de Microsoft, pero es probable que haya algunas diferencias.


Ah, ya veo, por lo que es intencional en la medida en que se basa en una instancia anterior de la ortografía. Todavía no me gusta, pero al menos puedo entender cómo llegó a ser. Gracias por una excelente respuesta.
Alec

66
Tenga en cuenta que si bien XML y URL son generalmente mayúsculas, las referencias a http en minúsculas están en todas partes en HTML. Por XMLHttpRequestlo tanto, se puede ver como la carcasa de camello de los identificadores combinados.
hardmath

2
Si regresas a la primera revisión en CVS: bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/base/... Es así. El autor original fue Vidur Apparao, por lo que tal vez alguien pueda rastrearlo (actualmente es CTO en Agari: agari.com/team/vidur-apparao ) y preguntarle. Desafortunadamente, no hay nada en Bugzilla sobre esto, en los días de Netscape no eran geniales para archivar errores para rastrear el trabajo.
Ted Mielczarek

4

Algunas pautas de nomenclatura hacen una distinción entre acrónimos "cortos" y "largos". Por ejemplo, la guía de estilo de codificación para el tiempo de ejecución .Net de Microsoft especifica que los acrónimos cortos deben estar en mayúsculas, mientras que los acrónimos largos solo deben tener la primera letra en mayúscula. Su umbral para un acrónimo largo es de 3 letras, por lo que favorecería "XmlHttpRequest", sin embargo, no es irracional pensar que algunas personas pueden usar una regla similar con 4 caracteres como umbral.

He visto copias antiguas de la guía de estilo mozilla.org, y ninguna parece especificar nada acerca de los acrónimos, pero es posible que una guía Netscape más antigua lo hiciera o que el desarrollador estuviera aplicando una regla que había recogido en otro lugar.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.