¿Por qué se rechazó a los Operadores Null-Safe (p. Ej., "Operador de Elvis") como parte del "Proyecto Moneda" de Java 7?

10

Una de las características propuestas para "Project Coin" de Java 7 fue el "operador de Elvis". Un informe de una presentación de JavaOne de 2009 sobre Project Coin lo describió como tal:

Una de las "pequeñas características" cubiertas en esta presentación es el llamado "operador de Elvis", una versión más concisa del operador ternario. Me encuentro extrañando algunas de las características de Groovy cuando uso Java tradicional y este sería un operador que podría usar en ambos idiomas si se agregara. El operador "Elvis" es útil para especificar un valor predeterminado que se puede usar cuando la expresión evaluada es nula. Al igual que el operador de navegación segura de Groovy, es una forma concisa de especificar cómo evitar nulos innecesarios. He bloggeado anteriormente sobre cómo me gusta evitar la NullPointerException.

Mientras que otros aspectos del Proyecto Coin finalmente se implementaron, este no. ¿Por qué el operador de Elvis fue rechazado en última instancia, a pesar de ser presentado en JavaOne como un posible candidato para la inclusión?

Para ser claros, estoy preguntando específicamente sobre este operador y la razón por la que fue rechazado como parte de "Project Coin" de Java 7, dado que se consideró seriamente en ese momento. Sospecho que hay listas de correo o similares donde se discutieron las razones para rechazarlo, pero no pude encontrar nada. Si hay información más general sobre por qué no se incluye en ninguna versión de Java, eso es aceptable pero no preferido.

java api-design Forja del Trueno
fuente
44
¿mentes sospechosas?
Ewan
1
Mot probablemente porque apoya y fomenta el uso de valores nulos como valores legítimos, y más fundamentalmente es contrario a los principios OO porque verifica el tipo de un objeto antes de ejecutar un método.
JacquesB
A menos que alguien vaya a desenterrar documentos explícitos (correos electrónicos, notas, transcripciones) del proceso de decisión o sea un participante directo de la decisión, realmente no podemos saber la respuesta aquí. Por ejemplo, la respuesta de Robert es solo especulación y consideraciones generales de diseño del lenguaje, no una razón objetiva y específica para el rechazo de este operador. Por lo tanto, voto para cerrar esta pregunta como basada en la opinión.
amon
1
@amon: Admití libremente que mi respuesta fue especulación al comienzo de mi publicación. Sin embargo, publiqué una respuesta de todos modos porque 1. Estoy enseñando a pescar en lugar de dar un pez, y 2. Esta publicación puede usarse como un objetivo para los incautos, si jugamos bien nuestras cartas. La idea detrás de una respuesta que proporciona un análisis general es desalentar argumentos interminables sobre decisiones de lenguaje minuciosas y ayudar a otros a ver una visión más amplia de los problemas generales.
Robert Harvey
@RobertHarvey A Sería conveniente el objetivo de engaño canónico “¿Por qué el lenguaje X no tiene la función Y?”, Pero la pregunta en su forma actual no parece adecuada para eso. Si se editara para hacer esta pregunta general (usando X = Java / Y = ?.como ejemplo ), ciertamente sería demasiado amplia como una pregunta ordinaria, pero tendría una buena respuesta.
amon

Respuestas:

15

Naturalmente, la mejor persona para hacer esta pregunta es alguien en el Comité Ejecutivo de JCP, no nosotros. Sin embargo, eso no me impedirá participar en una especulación ociosa.

La respuesta a cada pregunta de "por qué no se implementó esta característica" es siempre porque los beneficios no excedieron los costos.

Eric Lippert (ex miembro del equipo de C #) dice que, para que un producto tenga una característica, esa característica debe ser:

  • pensado en primer lugar
  • deseado
  • diseñado
  • especificado
  • implementado
  • probado
  • documentado
  • enviado a los clientes

En otras palabras, debe haber muchas cosas importantes que deben suceder antes de que se pueda realizar una nueva característica del lenguaje de programación. Los costos son mayores de lo que cree que son.

En el equipo de C #, cada solicitud de nueva característica comienza con una puntuación de menos 100. Luego, el equipo evalúa los beneficios y los costos, sumando puntos por los beneficios y restando puntos por los costos. Si la puntuación no supera el cero, la característica propuesta se descarta sumariamente. En otras palabras, la nueva característica debe proporcionar un beneficio convincente.

Pero el operador de Elvis lo convirtió en C #. Entonces, ¿por qué no llegó a Java?

A pesar de sus aparentes similitudes, Java y C # tienen filosofías de lenguaje significativamente diferentes. Esto se evidencia por el hecho de que los programas empresariales Java tienden a ser grandes colecciones estructurales de arquitectura. La brevedad y la expresividad del lenguaje se sacrifican en el altar de la ceremonia y la facilidad de codificación. Los patrones arquitectónicos de software bien conocidos que todos los miembros del equipo de desarrollo pueden reconocer son preferibles a las comodidades del lenguaje.

Considere este intercambio de Reddit :

El operador de Elvis se ha propuesto para todas las versiones de Java desde 7, y se ha rechazado cada vez. Diferentes lenguajes caen en diferentes puntos a lo largo del espectro desde "puro" hasta "pragmático", y los lenguajes que implementan el operador de Elvis tienden a estar más hacia el extremo pragmático del espectro que Java.

Si tiene un equipo de profesionales Java de más de 15 años escribiendo un sistema de procesamiento de back-end altamente distribuido y altamente concurrente de algún tipo, entonces probablemente desee un gran grado de rigor arquitectónico.

Sin embargo, si tiene un equipo de nivel junior a medio, la mitad de los cuales emigró de Visual Basic, y los tiene escribiendo una aplicación web ASP.NET que en su mayoría solo realiza operaciones CRUD ... entonces podría ser excesivo diseñar un montón de AbstractFactoryFactoryclases para abstraer el hecho de que no tiene control sobre qué columnas son anulables en la base de datos heredada de mierda que debe usar.

Estas profundas diferencias en la filosofía del lenguaje se extienden no solo a la forma en que se usan los idiomas, sino a la forma en que se lleva a cabo el proceso de diseño del lenguaje en sí. C # es un lenguaje dictador benevolente . Para obtener una nueva función en C #, solo tiene que convencer a una persona: Anders Hejlsberg .

Java adopta un enfoque más conservador. Para obtener una nueva característica en Java, debe obtener el consenso de un consorcio de grandes proveedores como Oracle, IBM, HP, Fujitsu y Red Hat. Obviamente, ese proceso será más lento y presentará una barra más alta para las nuevas características del lenguaje.

La pregunta "¿por qué no se implementó la función x ..." siempre incluye implícitamente las palabras, "... si obviamente es una buena idea?" Como he demostrado adecuadamente aquí, la elección nunca es tan simple.

Robert Harvey
fuente
8
sarcasmo: porque las clases AbstractFactoryFactory son un buen indicador del rigor arquitectónico y no de la hinchazón de código. /sarcasmo.
Machado
2
@RobertHarvey Sus conclusiones sobre el papel de los comités en el diseño del lenguaje Java son demasiado simplistas. Si bien existe una colaboración con la comunidad y con los socios de la industria, la afirmación de que el lenguaje Java es "diseño por comité" es casi completamente incorrecta, y una explicación terrible (aunque triste, superficialmente creíble) para la pregunta de este póster.
Brian Goetz
55
La mayoría de las razones anteriores que enumeró: cada función de idioma es más grande de lo que cualquiera piensa, los presupuestos finitos (por esfuerzo, por cambio, por complejidad) son precisos. Y agregaría: no hacemos la función X porque pensamos que otras funciones Y y Z son mejores opciones. Además, también adoptamos un enfoque más conservador que otros idiomas, porque sabemos que cada característica interactúa con, o en algunos casos excluye, otras posibles características en el futuro. Queremos que Java siga siendo vibrante y relevante en 20 años, lo que necesariamente significa no incluir todas las características que pueden parecer geniales ahora.
Brian Goetz
1
@BrianGoetz: Dado que el problema parece ser la naturaleza peyorativa del término "diseño por comité" (notará que no menosprecié a Java de ninguna otra manera), he cambiado ligeramente mi respuesta para eliminar el término.
Robert Harvey
1
Solía ​​haber cierta rivalidad entre los diseñadores de C # y Java. C # fue considerado una estafa por los diseñadores de Java (y con razón). Los delegados de C # fueron rechazados por no estar "orientados a objetos", pero la verdadera razón fue porque aparecieron primero en C #. Es bueno pensar que es solo por razones racionales que algunas características se agregan o se omiten ... Lo dudo.
Frank Hileman