cuando veo fragmentos de código comoMétodos de extensión virtual en el próximo lanzamiento de Java 8
interface A {
void a();
void b() default { System.out.println("b"); };
void c() final { System.out.println("c"); };
}
tengo una pregunta. ¿Ya no tenemos suficiente sh * t en Java? ¿Por qué uno podría necesitar esto?
sugiero que mire esta conferencia: http://medianetwork.oracle.com/media/show/16999
Esto explica todo. Lo más interesante es permitir que una interfaz evolucione sin reescribir toda la base de código. Esta es la clave para permitir que una gran base de código evolucione y no se vuelva cada vez más lisiada.
Creo que el concepto de "métodos de extensión" no es más que la última oportunidad de hackear/corregir API mal diseñadas que han estado expuestas al "mundo externo". Solo azúcar sintáctico.
Sí, todas esas API mal diseñadas cuyos diseñadores no estaban dotados de clarividencia o no podían diseñar su interfaz de manera diferente porque algunas características no existían;) – Voo
@Voo Los diseñadores de API no necesitan ser clarividentes darse cuenta de que puede haber métodos que deben agregarse más adelante. Podría haber usado clases abstractas, aunque el lenguaje es deficiente porque no permite la definición de una clase abstracta "pura" sin agregar el equipaje de compatibilidad binaria no deseado de una interfaz. –
Oh, "métodos de defensa" en realidad. –
Necesitamos esto porque pondrá a los chicos de Scala absolutamente furiosos. Ya tienen una funcionalidad bastante similar en forma de 'rasgos', por lo que ahora tendrán que hacer que funcionen junto con estos.
Orillarse sin control Scala guys es literalmente la más alta prioridad en el desarrollo del lenguaje Java.
En realidad, creo que los métodos de extensión virtual son una [implementación muy incompleta] (http://codecrafter.blogspot.ca/2012/06/java-8-virtual-extension-methods-are.html) de rasgos, y podrían pintar a sí mismo en una esquina. –
Obviamente, Jordão es un chico scala, así que el plan está funcionando. – ryber
+1 ¡Me hizo reír! –
Esto es excelente porque le permite a usted escritor de API extender las interfaces post-hoc sin causar NoSuchMethodErrors. También proporciona implementaciones predeterminadas para los métodos en V2 para las clases compiladas en V1; el código funciona como un encanto. Esto también le permite anular la implementación predeterminada en las clases compiladas contra V2 como de costumbre, y hace que las interacciones numeradas sean redundantes. Lo considero también superior a los métodos de extensión del sitio de uso.
por lo que es básicamente una ayuda para los escritores jdk, ¿verdad? –
No, es una ayuda para los escritores de bibliotecas, que ahora pueden ampliar sus interfaces (API) en V1.1 sin necesidad de cambiar el nombre a 2.0 y que requieren una recompilación. –
¿cómo es? seguro que necesitan cambiar el código en alguna parte. –
Está previsto que Java 8 contenga alguna forma de soporte lambda y de cierre, lo que sería un gran paso en la modernización del lenguaje Java. El problema es que las bibliotecas existentes basadas en interfaces, como el marco de recopilación, no podrán usar directamente estas nuevas características. No es posible agregar un método a una interfaz sin romper las implementaciones existentes, simplemente no volverían a compilar.
Tener lambdas, pero no ser capaz de usarlos fácilmente con colecciones estándar, sería una gran decepción para los desarrolladores de Java. Para integrar lambdas en las colecciones estándar, serían muy deseables métodos como forEach, map o filter.
La solución a este problema es agregar otra característica, los métodos de extensión, que definen una implementación predeterminada de un método en una interfaz. Las subclases existentes utilizarían el método predeterminado, pero también es posible anular el método con una mejor implementación especializada y posible.
Puede encontrar más información sobre la propuesta del método de extensión en Java Enhancement Proposal 126.
Y por exactamente las mismas razones por las que serán tan extremadamente útiles para lambdas, también ayudarán a otras API. Finalmente no hay 'interfaz X',' X2', .. ¡más! Ya era hora. – Voo
Esta es una gran extensión de imo, que acercará Java al mundo de la herencia múltiple sin todos sus complicados detalles de implementación. – Perception
@Perception "... sin todos sus complicados detalles de implementación ..." ¿cómo exactamente? –
Cadena de constructores, Choque de nombres potenciales, Ambigüedad polimórfica, no se habla demasiado de la complejidad adicional que tendría que definirse en el compilador. Todas las razones por las cuales las mixinas son más populares que la herencia múltiple en muchos idiomas modernos, y en lo que esta característica me recuerda más. – Perception