Est-ce une limitation du CLR ou existe-t-il des problèmes de compatibilité avec le code existant?Pourquoi la covariance/contravariance de C# 4.0 est-elle limitée aux types d'interface et de délégué paramétrés?
Est-ce lié à la variance ratée de la combinaison de délégués en C# 4.0?
Modifier: Serait-il possible d'avoir une langue utilisant la co-/contravariance sans que cette limitation s'exécute sur le CLR?
La réponse est simple: il est une limitation du CLR.
(je ne l'ai pas vu une bonne explication concrète pour ce partout ... Je ne me souviens pas avoir vu un dans la série blog d'Eric à ce sujet, bien que je puisse bien avoir manqué quelque part.)
Une chose que je dirait est que les délégués et les interfaces forment déjà des "couches d'indirection" sur les types réels; vues sur les méthodes ou les classes, si vous voulez. Passer d'une vue à une autre est assez raisonnable. La classe actuelle me semble être une représentation plus concrète - et passer d'une représentation concrète à une autre me semble moins raisonnable. C'est une explication très délicate, plutôt qu'une véritable limitation technique.
Cela semble plutôt mauvais. Donc, en gros, Microsoft répète l'erreur que Sun a fait avec Generics? Ou est-il prévu de lever ces restrictions dans une future mise à jour du CLR? – soc
La mise en œuvre n'est pas une 'erreur' - c'était une décision de conception explicite à laquelle ils pensaient, et ils ont des raisons de l'implémenter comme ils l'ont fait. – thecoop
@soc: Ce n'est * rien * comme les erreurs de Sun avec les génériques. Qu'ils pourraient l'autoriser dans une future version est la conjecture de quelqu'un. –
Vous voulez lire le post d'Eric Lippert sur les raisons pour lesquelles cela fonctionne comme il le fait. En bref, ils autorisent le plus de variance possible sans permettre aux développeurs de faire de mauvaises erreurs dans la programmation, ce qui pourrait rendre difficile la traçabilité des erreurs. La quantité de variance dans 4.0 est considérablement augmentée au-dessus des règles 3,0, et de ce que je comprends c'était un équilibre entre ce qui est bénéfique pour le développeur et ce qui est sûr de permettre sans causer trop de mal de tête par des erreurs involontaires.
http://blogs.msdn.com/b/ericlippert/archive/tags/covariance+and+contravariance/default.aspx
Bien que je puisse comprendre les préoccupations au sujet de la facilité d'utilisation, Java a eu cela pendant des siècles avec très peu de problèmes. Je pourrais imaginer que ces restrictions créent des solutions de contournement plus complexes et problématiques que cela simplifie les choses. – soc
Les génériques Java et .NET sont implémentés de manière complètement différente - Java est temps de compilation, .NET est l'exécution. Et l'ajout de fonctionnalités (variance de classe) crée toujours plus de travail et plus de problèmes à prendre en compte qu'autrement. – thecoop
@thecoop: Vous avez parlé du point de vue des développeurs dans votre réponse, pas des difficultés techniques sur le plan de la mise en œuvre. Ainsi, les détails de l'implémation de la façon dont la variance est implémentée sur la JVM/CLR ne sont pas vraiment une préoccupation du développeur. – soc
Il s'agit d'une limitation CLR. Voir Why does C# (4.0) not allow co- and contravariance in generic class types? pour un commentaire supplémentaire.
En quoi la variance de délégué C# est-elle 'corrompue'? – thecoop
@thecoop: http://stackoverflow.com/questions/2306814 – soc
Notez que le commentaire d'Eric dit que le délégué * combinant * est complètement foiré par rapport à la variance - pas les délégués génériques en général. –