Operador de diamante Java 7: ¿por qué fue difícil de implementar?

java-7 diamond-operator

Question

Vi el Evento Virtual Oracle OTN: Java SE y JavaFX 2.0 (28 de febrero de 2012) y mientras hablaba sobre el nuevo operador de diamante (ese Map<String, List<String>> myMap = new HashMap<>(); cosa) el orador mencionó que no era tan simple de implementar como se podría pensar, ya que no es un simple reemplazo de token.

Mi pregunta es ¿por qué? ¿Por qué no se puede implementar esto simplemente tomando la cadena de la declaración de la variable y colocándola en el operador de diamante?

Answer 1

Algo que Java no hace (que tienen muchos lenguajes) es tipos implícitos basados ​​en el uso. es decir, Java no implica un tipo de requerimiento basado en cómo se usa.

p.ej

 Type a = b;

El tipo de a y el tipo de b son independientes y no se hacen suposiciones sobre b función del tipo de a .

MethodHandles está mostrando signos de apoyo a esto. El uso del tipo de retorno puede basarse en el contexto, pero esta es una característica de tiempo de ejecución.

En conclusión, mi suposición es; Fue difícil de implementar en Java porque el lenguaje no era compatible con ninguno similar. Si el lenguaje utilizara características como esta todo el tiempo, el enfoque a tomar se entendería (en términos de definir una especificación de cómo debería funcionar) y sería compatible con las herramientas del compilador.

Answer 2

Yo tampoco lo implementé, así que solo puedo adivinar.

Pero generalmente la razón por la que estas cosas son más complejas de lo que parecen es que la primera inspección solo se refiere al caso de uso más común (o más publicitado). En este caso es el que mencionaste. En teoría, debería ser fácil de especificar exactamente y debería ser bastante fácil de implementar en un compilador.

Sin embargo, el operador de diamante (que, por cierto, no es técnicamente un operador) también se puede utilizar de diferentes maneras:

someMethodWithGenericArguments(new HashMap<>());
new SomeGenericClass(new HashMap<>());
T foo = new SomethingRelatedToT<>(); // where T is a generic type parameter

En esos casos, obviamente, un reemplazo de token simple ya no funciona, necesita inferencia de tipo real que involucre análisis de tipo real (es decir, se encuentra en un nivel de abstracción completamente diferente como lo sería un reemplazo de token simple).