¿Por qué no habrá propiedades nativas en Java 7?
properties java-7 (5)
Cualquier cosa dada está "no hecha" por defecto, por lo que no se necesita una razón particular para que algo no se haga. Más bien, se necesita alguna razón convincente para mover algo de "no hecho" a "planeado" o "hecho". Aún no ha surgido una razón suficientemente convincente para esta característica de lenguaje.
¿Hay alguna razón racional por la que las propiedades nativas no formarán parte de Java 7?
Hacer las propiedades "bien" en Java no será fácil. El trabajo de Rémi Forax, especialmente, ha sido valioso para averiguar cómo podría ser esto, y para descubrir muchos de los "errores" con los que habrá que lidiar.
Mientras tanto, Java 7 ya ha tardado demasiado. El debate sobre los cierres fue una distracción enorme y controvertida que desperdició una gran cantidad de poder mental que podría haberse utilizado para desarrollar características (como propiedades) que tienen un amplio consenso de apoyo. Finalmente, se tomó la decisión de limitar los cambios importantes a la modularización (Project Jigsaw). Solo se está considerando el "pequeño cambio" para el idioma (bajo Project Coin).
JavaFX tiene un excelente soporte de propiedades, por lo que Sun entiende claramente el valor de las propiedades y sabe cómo implementarlas. Pero como las propiedades JavaFX han echado a perder, es menos probable que los desarrolladores se conformen con una implementación a medias en Java. Si vale la pena hacerlo, vale la pena hacerlo bien.
Hay algunas razones de alto nivel relacionadas con el calendario y los recursos, por supuesto. La implementación de propiedades y la comprensión de todas las ramificaciones e intersecciones con otras características de lenguaje es una tarea grande similar al tamaño de varios cambios de lenguaje de Java 5.
Pero creo que la verdadera razón por la que Sun no está presionando las propiedades es lo mismo que los cierres:
1) No hay consenso sobre cómo debería ser la implementación. O, más bien, hay muchas alternativas en competencia y las personas que sienten pasión por las propiedades no están de acuerdo con las partes cruciales de la implementación.
2) Quizás lo que es más importante, hay una falta significativa de consenso acerca de si la característica se desea o no. Si bien mucha gente quiere propiedades, también hay mucha gente que no cree que sea necesaria o útil (en particular, creo que las personas del lado del servidor consideran que las propiedades son mucho menos cruciales para su vida diaria que los programadores de swing).
Historia de las propiedades aquí:
Hay dos razones más para evitar propiedades en cualquier idioma:
Las propiedades no son muy orientadas a objetos. Hacer que sean fáciles de escribir fomenta el patrón en el que el objeto solo cumple su estado interno y el llamante lo manipula. El objeto debe proporcionar métodos de nivel superior y mantener sus aspectos internos privados. La próxima vez que esté implementando tediosamente un captador, considere qué hará la persona que llama con los datos y si puede proporcionar esa funcionalidad directamente.
Las propiedades fomentan el estado mutable (a través de los establecedores), lo que hace que un programa sea menos paralelizable. A medida que aumenta el número de núcleos, todos debemos intentar que nuestros objetos sean inmutables para facilitar el razonamiento concurrente. La próxima vez que esté implementando tediosamente un setter, considere eliminarlo y hacer que el objeto sea inmutable.
- ¿No hay tiempo suficiente?
- ¿Todavía no se ha especificado correctamente?
- ¿Difícil de agregar a java debido a la implementación de java?
- Considerado no lo suficientemente importante, es decir, otras cosas fueron priorizadas?