c# - method - ¿Por qué no delegados de estilo.NET en lugar de cierres en Java?

list delegate c# (2)

C # tiene cierres además de los delegados. En mi opinión no son lo mismo.

delegado = puntero a función.

cierre = {función, entorno}. Forma de definir una función [anónima] y empaquetarla con su entorno. Estrictamente hablando, este último solo debe llamarse cierre, el primero es "expresión lambda".

OK, esta va a ser mi vencer a un caballo moribundo por tercera vez.

Sin embargo, esta pregunta es diferente de mis dos anteriores sobre cierres / delegados, que pregunta sobre los planes para los delegados y cuáles son las especificaciones proyectadas y la implementación para los cierres.

Esta pregunta es acerca de: ¿por qué la comunidad de Java está luchando para definir 3 tipos diferentes de cierres cuando podríamos simplemente robar todo el concepto de bloqueo, stock y barril de los delegados de nuestro querido y amigable vecino, Microsoft?

Hay dos conclusiones no técnicas con las que me sentiría tentado a saltar:

La comunidad de Java debe mantener su orgullo, al costo de la necesidad de ir a través de esfuerzos complicados, al no sucumbir al pedir prestado ningún concepto de Microsoft o de otro modo reivindicar la brillantez de Microsoft.
Los delegados es una tecnología patentada de Microsoft.

Muy bien, además de las dos posibilidades anteriores,

Q1. ¿Hay alguna debilidad o inadecuación en los delegados de estilo .NET que las tres (o más) formas de cierres abordarían?

Q2. Estoy preguntando esto mientras cambio entre Java y C # y me intriga que los delegados de C # hagan exactamente lo que necesitaba. ¿Existen características que se implementarían en cierres que actualmente no están disponibles en los delegados de C #? Si es así, ¿cuáles son porque no puedo ver lo que necesito más de lo que los delegados de C # me han proporcionado adecuadamente?

Q3. Sé que una de las preocupaciones sobre la implementación de cierres / delegados en java es la reducción de la ortogonalidad del lenguaje, donde se expone más de una forma para realizar una tarea en particular. ¿Vale la pena el nivel de convolución y el tiempo empleado para evitar delegados solo para garantizar que java mantenga su nivel de ortogonalidad? En el diseño relacional, sabemos que es aconsejable romper la ortogonalidad, satisfaciendo con frecuencia adecuadamente solo la segunda forma normal. ¿Por qué no se puede someter a Java a la reducción de la ortogonalidad y la OO-ness en aras de la simplicidad?

Q4. La arquitectura de JVM está técnicamente limitada a la hora de implementar delegados de estilo .NET. Si esta razón fuera WERE (subjuntivo para enfatizar la improbabilidad), entonces ¿por qué no se pueden ocultar las tres propuestas de cierres detrás de una simple palabra clave o anotación de delegado? No puedo ver cómo el formato de declaración de delegado es más complejo que las tres propuestas de cierre.

Tu pregunta es irónica. ¿Se pregunta por qué la comunidad de Java está luchando con tres propuestas diferentes para agregar cierres y su solución sugerida es agregar una cuarta opción a la combinación?

Pero para responder a su pregunta:

El foro adecuado para el debate es la lista de correo de openjdk project lambda. Este no es un lugar donde las sugerencias puedan influir en ese esfuerzo.
Los sistemas de tipo para C # y Java son significativamente diferentes, por lo que la solución de C # no se aplicaría directamente. Por ejemplo, C # tiene variación de sitio de declaración (entrada / salida), mientras que java tiene variación de sitio de uso (comodines). La inferencia de los tipos de parámetros lambda como se especifica en C # no se aplicaría en Java.
La evolución de Java debe seguir siendo compatible con versiones anteriores, pero agregar la palabra clave delegada sería un cambio importante.
C # tiene tres tipos de expresiones delegadas: la antigua con la palabra clave delegada, la declaración lambdas con => {y la expresión lambda. Si el equipo de lenguaje C # tiene que volver a hacerlo, ciertamente no tendremos tantas formas. ¿Por qué debería adoptar Java el equipaje histórico de C #?
Debido a que los genéricos C # operan sobre primitivos, los tipos de delegado Func <> y Action <> se pueden usar como tipos de función estructural de hombre pobre. Pero en Java, los genéricos se borran, funcionan solo sobre tipos de referencia, y los tipos no pueden distinguirse por su aridad. En consecuencia, Java tendría que tener un gran número de tipos de funciones "estándar" con distintos nombres para obtener el mismo efecto. Eso no sería bonito.

En general, la solución C # no se adapta a una solución muy natural en Java.