Discussion :

[GuruuMeditation]

Bonjour,

Mon premier article est en ligne, il parle d'une nouveauté méconnue de .NET 4.0 : la variance en C# 4.0.
Les suggestions/commentaires sont bienvenus !

Bonne lecture!

[DonQuiche]

Bonjour à toi.
Et avant tout, bonne initiative.

Première remarque : une légère incohérence dans le plan. La section (2b) sur la création d'interfaces et de délégués covariants est une sous-section de la covariance (2) tandis que son pendant sur les contravariants est une section à part (4), distincte à la section sur la contravariance (3).

Second remarque : dans l'introduction tu affirmes que la covariance et la contravariance ont été introduites avec dotnet 4.0. Tu corriges plus tard en précisant que dotnet supportait déjà la covariance de tableaux (mais aussi les délégués covariants). Du coup l'intro m'a un peu fait tiquer.

Troisième remarque : rien sur l'implémentation ou les performances. Le lecteur pourrait penser qu'il s'agit d'un truc du compilateur qui créerait un wrapper autour de la structure originale (ce qui impliquerait une allocation et tout le bazar). Il me semble important de préciser que covariance et contravariance sont en fait gérées au niveau du clr lui-même, par exemple en montrant que le code IL est inchangé quand on use ou non de la co/contravariance. Et donc que le concept est portable entre langages (même si certains compilateurs non à jour peuvent signaler des erreurs). Enfin, j'aurais personnellement aimé voir quelle est le coût sur les performances : je soupçonne qu'il est faible mais je ne l'ai jamais mesuré.

[antoine.debyser]

Bonjour,

Oula voila un sujet pas facile à traiter, je vais m'empresser de le lire, ayant quelques lacunes sur le sujet

[GuruuMeditation]

Bonjour à toi.
Et avant tout, bonne initiative.

Première remarque : ...

Merci pour les encouragements (et les remarques, vu qu'elles sont constructives).
Effectivement, remarques judicieuses. Je ferais bien, d'ici la fin de l'année, une version 1.1 de l'article (on peut faire ça?) en tenant compte de tout ça. Avec une section supplémentaire pour ta troisième remarque.

[Max]

Salut.

D'après moi, un article sur ce sujet manquait clairement sur DVP.

Donc c'est cool de l'avoir écrit, et encore plus de l'avoir bien fait . Avec une mention particulière pour le choix des exemples, les fruits ou les animaux facilitant grandement l'approche des concepts par rapport à T et U.

Bravo .

[antoine.debyser]

Ca y est, j'ai lu, et commencer à digérer l'article.

Très bon point, on comprend parfaitement de quoi il s'agit, et les exemples sont bien choisit.

D'après moi, un article sur ce sujet manquait clairement sur DVP.

Exacte, il manquait même un bon article en français.

Pour autant y'a des choses flou, d'ailleurs DonQuiche a commencé à pointer le problème.
De la variance on en fait tous les jours

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

object toto = new MaClass()

C'est de la covariance, et le framework a toujours gérer cela. La nouveauté c'est le support de la variance sur les générique. Même si on peut pas encore tout faire, comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

IList<object> list = new List<string>()

D'ailleur je ne comprend pas le problème avec IList<T>, il doit surement avoir une raison, la méthode "CopyTo" peut-etre?

[tomlev]

D'ailleur je ne comprend pas le problème avec IList<T>, il doit surement avoir une raison, la méthode "CopyTo" peut-etre?

La covariance ne fonctionne que si le type pour lequel l'interface est covariante ne se trouve qu'en position de sortie (par exemple dans IEnumerable<T>, T est seulement en sortie, jamais en entrée). Or dans IList<T>, T se retrouve aussi bien en entrée qu'en sortie (par exemple la méthode Add(T item)), la covariance ne peut donc pas fonctionner. Si IList<T> était covariante, ça "casserait" la sécurité de type, parce qu'on pourrait avoir à l'exécution des erreurs de typage :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
IList<object> list = new List<string>();
list.Add(DateTime.Now);

Si la première ligne était valide, ce code compilerait sans problème (un DateTime étant un object), mais ça planterait à l'exécution, car on ne peut pas ajouter un DateTime à une collection de String.

Le problème existe déjà pour les tableaux, qui sont covariants depuis .NET 1 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
object[] array = new string[1];
array[0] = DateTime.Now;

Ce code compile, mais provoque une ArrayTypeMismatchException. Voir cet article pour plus d'infos à ce sujet

[DonQuiche]

De la variance on en fait tous les jours

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

object toto = new MaClass()

C'est de la covariance, et le framework a toujours gérer cela.

Non, à strictement parler ce n'est pas de la covariance, c'est du simple polymorphisme. On parle de covariance ou de contravariance quand les règles du polymorphisme sont étendues à des compositions/fonctions/applications de type. Il faut se référer la théorie des catégories.

Pour résumer : si T assignable à U (polymorphisme), f:X->T est assignable à f:X->U (covariance).

Pour IList<T>, je pense que la raison est qu'assigner un List<String> à un IList<Object> peut ensuite conduire l'utilisateur à tenter d'ajouter autre chose qu'une string à la liste et que cela pue le design bancal à cent mètres. Cela dit cette raison n'a pas empêchée l'équipe dotnet d'autoriser la covariance de tableaux (une erreur selon moi, qui a fait débat à l'époque dans l'équipe des concepteurs de dotnet et qui a malheureusement entraîné un coût pour toutes les assignations dans des tableaux).

[Er3van]

Enfin, j'aurais personnellement aimé voir quelle est le coût sur les performances : je soupçonne qu'il est faible mais je ne l'ai jamais mesuré.

Je déterre la discussion car je me suis posé la question hier.
Est-ce que quelqu'un a eu l'occasion de tester ce point?

Par défaut je ne pense pas que ça ait d'impact sur les performances, mais la question est judicieuse et j'avoue que je ne sais pas du tout si cela a un impact au niveau du CLR, particulièrement sur des gros volumes d'objets.

A défaut de réponse j'en donnerai surement une d'ici quelques semaines !