¿Es esto una limitación del CLR o hay problemas de compatibilidad con el código existente?¿Por qué la covarianza/contravarianza de C# 4.0 se limita a la interfaz parametrizada y tipos de delegados?
¿Está esto relacionado con la variación desordenada de la combinación de delegados en C# 4.0?
Editar: ¿Sería posible tener un lenguaje usando co-/contravariancia sin que esa limitación se ejecute en el CLR?
Respuesta simple: se trata de una limitación CLR.
(no he visto una buena explicación concreta para esto en cualquier lugar ... No recuerdo ver uno en serie el blog de Eric al respecto, aunque bien podría haber perdido en alguna parte.)
Una cosa que sería decir es que tanto los delegados como las interfaces ya forman "capas de indirección" sobre los tipos reales; puntos de vista sobre métodos o clases, si lo desea. Cambiar de una vista a otra es bastante razonable. La clase real se siente como una representación más concreta para mí, y pasar de una representación concreta a otra se siente menos razonable. Sin embargo, esta es una explicación muy sensible, más que una limitación técnica genuina.
Eso suena bastante mal. ¿Básicamente, Microsoft repite el error que Sun cometió con Generics? ¿O está previsto levantar estas restricciones en una futura actualización del CLR? – soc
La implementación no es un "error": fue una decisión de diseño explícita en la que pensaron, y tienen motivos para implementarla de la manera en que lo hicieron. – thecoop
@soc: No es * nada * como los errores de Sun con los genéricos. No se sabe si podrían permitirlo en una versión futura. –
Vas a querer leer la publicación de Eric Lippert sobre por qué funciona de la manera que lo hace. En resumen, permitieron la mayor variabilidad posible sin permitir a los desarrolladores cometer errores graves en la programación que podrían dificultar la localización de errores. La cantidad de varianza en 4.0 se ha ampliado considerablemente en comparación con las reglas 3.0 y, según tengo entendido, fue un equilibrio entre lo que es beneficioso para el desarrollador y lo que es seguro permitir sin causar demasiado dolor de cabeza debido a errores involuntarios.
http://blogs.msdn.com/b/ericlippert/archive/tags/covariance+and+contravariance/default.aspx
Aunque puedo entender las preocupaciones sobre la usabilidad, Java tuvo esto por años con muy pocos problemas. Podría imaginarme que estas restricciones crean soluciones más complejas y problemáticas que simplifican las cosas. – soc
Los genéricos de Java y .NET se implementan de formas completamente diferentes: Java es el tiempo de compilación, .NET es el tiempo de ejecución. Y agregar características (variación de clase) siempre crea más trabajo y más problemas para considerar que de lo contrario. – thecoop
@thecoop: Habló sobre el punto de vista de los desarrolladores en su respuesta, no sobre las dificultades técnicas en el lado de la implementación. Entonces, los detalles de implementación de cómo se implementa la varianza en JVM/CLR no son realmente una preocupación del desarrollador. – soc
Es una limitación de CLR. Ver Why does C# (4.0) not allow co- and contravariance in generic class types? para comentarios adicionales.
¿Cómo está la variación del delegado C# 'en mal estado'? – thecoop
@thecoop: http://stackoverflow.com/questions/2306814 – soc
Tenga en cuenta que el comentario de Eric dice que delegar * combinar * es todo un desastre con respecto a la varianza, no delegados genéricos en general. –