Discussion :

[maa]

Bonjour,

Je trouve que les generics pourraient être largement améliorés dans une future version du framework. Je pense à :
- la possibilité de contraindre un type paramètre à avoir un constructeur avec paramètre ;
- la possibilité de parcourir les type paramètres d'un type paramètre sous contrainte de dérivation et de les utiliser comme type paramètre ;
- la covariance et la contravariance des types paramètres d’une classe générique ;
- l'inférence d'une partie des type paramètres (actuellement si tous les types paramètres ne peuvent pas être inférés alors on doit tous les préciser...)

Pensez-vous que des amélioration sur les generics seront faite dans le version 4 ? Avez-vous en tête d'autre améliorations qui pourraient être faites ?

[SaumonAgile]

j'ai du mal à comprendre ce que tu attends de nous

[Thomas Lebrun]

Ce n'est pas (encore) un débat à proprement parlé donc je déplace pour le moment

[Sphax]

Bonjour,

Je trouve que les generics pourraient être largement améliorés dans une future version du framework. Je pense à :
- la possibilité de contraindre un type paramètre à avoir un constructeur avec paramètre ;
- la possibilité de parcourir les type paramètres d'un type paramètre sous contrainte de dérivation et de les utiliser comme type paramètre ;
- la covariance et la contravariance des types paramètres d’une classe générique ;
- l'inférence d'une partie des type paramètres (actuellement si tous les types paramètres ne peuvent pas être inférés alors on doit tous les préciser...)

Pensez-vous que des amélioration sur les generics seront faite dans le version 4 ? Avez-vous en tête d'autre améliorations qui pourraient être faites ?

Je ne suis pas sur de comprendre les 3 derniers points. Peux-tu développer (en donnant des exmples de ce que tu souhaites pouvoir faire) ou me renvoyer vers des explications ?

Sinon de mon côté ce que je trouve gênant comme limitation avec les génériques .net c'est l'impossibilité d'utiliser la surcharge d'opérateur des types fournies (c'est à dire qu'il est impossible de faire une opération de type T+T même si la classe T surcharge l'opérateur + vu que cette surcharge ne peut être indiquée au moyen d'une interface, je sais pas si je suis clair...).
Ce qui limite l'utilisation des génériques à des classes conteneurs comme les listes, les tableaux etc... sans pouvoir faire des types génériques mathématiques.

EDIT: article intéressant sur la variance des types génériques. C'est un peu chaud de tout saisir sans emmeler tous les concepts, mais si je comprends bien le CLR supporte la variance des génériques et c'est une décision de l'équipe C# de pas le suporter : http://blogs.msdn.com/rmbyers/archiv...16/375079.aspx

[maa]

Voici une explication plus détaillée de dont je perlais :

deuxième point, voici un exemple :
voici ce que l'on doit écrire si l'on souhaite instancier et remplir une liste générique :

Code :

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

1
2
3
4
5
6
 
    public class GenericClass<U,T> where U : List<T>, new() where T : new()
    {
        U MyList =  new U();
        T Element = new T();
    }

Hors le type paramètre T n'est pas nécessaire, puisqu'il est déjà contenu dans U. J'amerais pouvoir m'en passer dans la définition de ma classe. Il faudrait alors un moyen dans ma méthode de dire : je veux le type paramètre de U (T), pour pouvoir l'instancier.

Pour le Troisième point, ton article explique bien le problème. L'auteur explique qu'il n'exclut pas la possibilité que la convariance soit implémentée dans une future version de C#. Même si ce n'est pas 'type safe', je trouverait bien pratique de laisser ou non la possibilité de l'utiliser. Qu'en penses-tu ? Je trouve que c'est un bon sujet de débat : vaut-il mieux empêcher ce genre de chose pour ne pas risquer d'avoir d'erreur à l'exécution ou laisser la possibilité de l'utiliser ou non... ?

Pour le quatrième point voici un exemple :

Code :

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

1
2
3
4
5
 
        public void Method<V,W>(V p1)
        {
 
        }

V peut être déduit du type de p1, mais pas W. Dans ce cas on doit préciser les 2 types paramètres alors qu'on pourrait simplement appeler la méthode comme cela :

Code :

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

Method<,MontTypeW>(monParametreDeTypeV)

Bon je l'accorde, ce n'est pas une grosse contrainte...

[davcha]

Pour le second point :

Code :

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

1
2
3
4
5
class G<T> where T : new()
{
	List<T> MyList = new List<T>();
	T Element = new T();
}

Non ?...

[maa]

Ca n'est pas la même chose. Dans mon exemple, je peux passer un liste qui hérite de List<T>.

[Sphax]

Pour le 3ieme point je suis mitigé, je comprends bien l'interêt d'avoir des vérification de types à la compilation mais on perd en flexibilité. Dilemme classique.

Mais j'insiste, pour moi les generics .net sont trés limités. Le système de contraintes est trop rigide et ne permet pas grand chose. En fait je ne vois pas de réelle gain entre

Code :

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

1
2
 
class Exemple<T> where T: IUneInterface

et

Code :

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

1
2
3
4
5
6
7
8
9
10
 
class Exemple
{
   private IUneInterface _membre;
 
   public Exemple(IUneInterface param)
   {
      _membre = param;
   }
}

Et finalement il n'y a plus vraiment de programmation générique, on est lié à une hiérarchie de classe/interface classique en POO.
J'ai vraiment l'impression qu'en gros les generics ont "simplement" servi à MS pour créer leurs conteneurs génériques et aussi éviter les problèmes de boxing des types valeurs dans les conteneurs.