Ha sido anunciado por Mark Reinhold en Devoxx. Hasta ahora, todas las noticias que habíamos tenido al respecto apuntaban a que las closures se quedarían fuera del JDK 7. por primera vez, un empleado de Sun involucrado directamente en el JDK 7 ha afirmado que si que se van a incluir, y que la propuesta será FCM.
La verdad, casi no me lo creo. Me parece un tanto precipitado. Entiendo perfectamente que es posible incluir la sintaxis de closures sin ningún problema, y sin requerir demasiado tiempo gracias a construir sobre las propuestas que ya están disponibles en Internet (como FCM). Pero esto sólo la mitad de la historia ¿qué pasa con todas las librerías estándar donde tendría sentido emplear closures? ¿Las van a rediseñar todas en un tiempo razonable? ¿No es ya un poco tarde para comenzar ese trabajo? ¿o es que la intención es sólo tener una sintaxis para soportar closures, sin modificar las librerías... lo cual sería un parche mal hecho?
Etiquetas: j2se, closures, jdk7
La propuesta es parecida, en su sintaxis, a FCM, pero no es FCM.
Al final, con precipitación. Doble contra sencillo a que no deja a nadie contento.
Me animo a apoyar la idea de incluir la sintaxis pero sin modificar las librerías (que tampoco estamos seguros de que sea lo que va a suceder), por los siguientes motivos:
Respecto a la idea de que "no deja a nadie contento"...bueno, hagan lo que hagan, un montón de gente se va a enojar, porque la arquitectura de un lenguaje siempre es una serie de compromisos, asi que eso es inevitable.
Y habrá que acostumbrarse a escribir el #, que al menos es menos tipeo que un lambda de python ...aunque parce que le hagamos publicidad a C#!
Los closures serviran para que despues en el JDK8 se cambien las librerias que necesitan de este tipo de implementacion. Yo no lo veo tan mal del todo...
Ayudenme, por favor! Tengo que implementar un método que reciba una List<> de métodos anónimos que reciben Listas de cualquier cosa que extienda de Number y los vaya llamando a cada uno repetidas veces con diversas listas de Integer, Float, Long, etc. Esos métodos anónimos devuelven a su vez Listas de cualquier cosa que extienda de JComponent y esas listas luego se recorren pintando el elemento que sea.
Me han comentado que es posible que esto en el futuro haya que implementarlo por medio de una anotación para inyectar la lista de Numbers a los métodos anónimos de forma automática, pero no me he enterado muy bien de esa parte y de todos modos por ahora no hay que hacerlo.
Gracias de antebrazo.
Que obsesion por modificar el lenguaje, ¿no hay otros lenguajes que usan la maquina virtual q tiene closures? , si se tiene tantas ganas de closures usar esos, prefiero el esfuerzo en mas librerias
un cordial saludo.
infoeduardo
Al anónimo de las 20:17, eso en realidad es muy sencillo.
void applyGenerators(List<#List(List)> generators, List components) {
// For a set or list
for (Iterator itg=generators.iterator(); itg.hasNext(); ) {
#List(List) gen = itg.next();
for (Iterator itc=components.iterator(); itc.hasNext(); ) {
gen.invoke(itc.next());
}
}
}
Un ejemplo de cómo usar esto es trivial.
Oh, no sale bien el código!
void applyGenerators(List<#List(List)> generators, List components) {
// For a set or list
for (Iterator itg=generators.iterator(); itg.hasNext(); ) {
#List(List) gen = itg.next();
for (Iterator itc=components.iterator(); itc.hasNext(); ) {
gen.invoke(itc.next());
}
}
}
Nada, que JH se come el código... http://pastebin.com/f66dcb29
Las closures van a a ser introducidas en Java ahora por dos motivos:
1.- Debido adquisición de Sun por parte de Oracle, el JDK 7 se ha visto retrasado mas de 6 meses, por lo que lo antes "no daba tiempo" a considerar, ahora sí da tiempo.
2.- Debido al retraso han pensado incluir un API de procesamiento en paralelo (ParallelArray) el cual sin usar Closures podría necesitar unos 160 interfaces diferentes para cubrir todos los casos posibles de combinaciones de tipos de datos básicos.
De ahí que hayan salido con estas. Eso sí, seran closures "simples" para evitar cosas raras como que un return en medio de una closure de salga del metodo que la ejecuta etc. En fin, parece que hay un caso-de-uso que sí mejoran.
Sin embargo, personalmente creo que la forma de hacerlo no ha sido la más apropiada. Pero vamos, Sun nunca ha sido una maravilla del marketing, por muy buenas que fueran sus intenciones, así que ninguna sorpresa por esa parte.
Hay vamos, cada vez más desvirtuando Java !!!
¿Son tan necesarias las closures? Hasta la fecha hemos pasado sin ellas ¿realmente son un aporte o sólo porque Groovy las tiene las quieren meter si o si en Java?
A veces pienso que todo esto es como un queso...
En mi opinión, dan flexibilidad al lenguaje ... que es de eso de lo que se trata ... si no las necesitas o si no las quieres utilizar ... pues bueno ... pero está bien saber que existen y tener la posibilidad de usarlas. ¿En javascript son realmente necesarias las closures? Sin embargo, creo que prácticamente todos los frameworks javascript actuales las usan ...
No me gustan, ensucian el código. Si alguien las quiere usar que las use, no me parecen lo mejor.
64574879122
¿Ensucian el código? Según esa teoría...un método de más de 20 líneas también ... ¿no debería permitirse tampoco?
Me parece que closures es algo que se necesitaba desde mucho tiempo. Permiten que código sea mas declarativo e intuitivo. Smalltalk hace 40 años que las usa, pero las llama bloques.
Escribe tu comentario