domingo
ene072007
Propuestas para mejorar el soporte de las propiedades en Java
domingo, enero 7, 2007 at 10:33PM
Si hay dos temas candentes respecto a las posibles modificaciones de lenguaje en Java 7 son las closures y las propiedades. El soporte que actualmente proporciona Java para las propiedades es bastante simple (convenios de nomenclatura, básicamente los típicos setX y getX).
Este soporte tan simple obliga a escribir código repetitivo y común a casi todos los casos de uso, pero propenso a fallos si, aunque sólo sea por aburrimiento, nos olvidamos de él. Ejemplos de este código son chequear las restricciones que debe cumplir una nueva propiedad que se modifica mediante el método setX (¿cuántas veces habéis mirado si esa propiedad era o no null?), lanzar un evento cuando se modifica una propiedad, realizar alguna acción (como repintar el componentes si es un componente gráfico), etc.
Danny Coward, un empleado de Sun, ha presentado una propuesta para las propiedades que añadiría una palabra reservada al lenguaje:
El añadir esta palabra reservada haría que se generasen de modo automático los métodos geters y seters. Además, se podría acceder a las propiedades mediante el operador -> por ejemplo:
Se podría escribir como:
Mikael Grev, autor de una entrada de Javalobby donde se discute en profundidad este tema propone emplear anotaciones:
Este ejemplo define una propiedad que no puede ser null, que genera un evento al cambiar su valor (sólo si éste realmente cambia) y que cuando cambia su valor invoca al método repaint().
Ambas propuestas pueden considerarse en cierto modo complementarias. No obstante, la de Danny Coward es más agresiva en el sentido de que supone cambiar el lenguaje, el compilador y las herramientas de desarrollo como los IDEs. La de Mikael Grev supondría muchos menos cambios y soluciona problemas (código repetitivo) que la otra no.
¿Cuál os gusta más? ¿creéis que es necesario mejorar el soporte de propiedades que haya java actualmente ?
Este soporte tan simple obliga a escribir código repetitivo y común a casi todos los casos de uso, pero propenso a fallos si, aunque sólo sea por aburrimiento, nos olvidamos de él. Ejemplos de este código son chequear las restricciones que debe cumplir una nueva propiedad que se modifica mediante el método setX (¿cuántas veces habéis mirado si esa propiedad era o no null?), lanzar un evento cuando se modifica una propiedad, realizar alguna acción (como repintar el componentes si es un componente gráfico), etc.
Danny Coward, un empleado de Sun, ha presentado una propuesta para las propiedades que añadiría una palabra reservada al lenguaje:
public property String name;
El añadir esta palabra reservada haría que se generasen de modo automático los métodos geters y seters. Además, se podría acceder a las propiedades mediante el operador -> por ejemplo:
bean.setName("Joe")
String name = bean.getName()
Se podría escribir como:
bean->name = "Joe"
String name = bean->name
Mikael Grev, autor de una entrada de Javalobby donde se discute en profundidad este tema propone emplear anotaciones:
@Property(bound = true, notnull = true, onChange = "repaint();")
public property Color color = Color.BLACK;
Este ejemplo define una propiedad que no puede ser null, que genera un evento al cambiar su valor (sólo si éste realmente cambia) y que cuando cambia su valor invoca al método repaint().
Ambas propuestas pueden considerarse en cierto modo complementarias. No obstante, la de Danny Coward es más agresiva en el sentido de que supone cambiar el lenguaje, el compilador y las herramientas de desarrollo como los IDEs. La de Mikael Grev supondría muchos menos cambios y soluciona problemas (código repetitivo) que la otra no.
¿Cuál os gusta más? ¿creéis que es necesario mejorar el soporte de propiedades que haya java actualmente ?
in
j2se
j2se 
Reader Comments