Ce qu'il manque dans les généric du framework 2

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 ?

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

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

Citation:

---

Envoyé par 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 ?

---

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

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:

---

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:

---

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:

---

Method<,MontTypeW>(monParametreDeTypeV)

---

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

Pour le second point :

Code:

---

1 2 3 4 5

class G<T> where T : new() { List<T> MyList = new List<T>(); T Element = new T(); }

---

Non ?...

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

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:

---

1 2	class Exemple<T> where T: IUneInterface

---

et

Code:

---

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.

Citation:

---

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.

---

Tu proposerais quoi comme type de contrainte ?

Citation:

---

Envoyé par maa

Tu proposerais quoi comme type de contrainte ?

---

En fait en y réfléchissant je ne suis pas sûr que mon message précédent soit trés pertinent. Je manque d'expérience en ce qui concerne les templates/generics il faut que j'y pense encore. Il me semble simplement d'aprés mes qques souvenirs des templates C++ que ceux-ci permettent bien plus de choses que les generics .Net mais qu'ils sont aussi trés compliqués (je me souviens en particulier de ce livre qui rend fou...). Peut être les generics sont-il un compromis entre fonctionnalités et simplicité.

Pour répondre à ta question je pense qu'il manque au moins des contraintes de type "T surcharge tel ou tel opérateur" pour pouvoir effectuer des opération arithmétiques sur des objets de type T.

Il est évident que les généric .NET sont incomplets vis à vis de ceux disponibles dans les templates sous C++.

Cependant comme tu l'a dit, ils sont définis comme des compromis entre le tout et n'importe quoi possible de C++ et la facilité. Car les templates de C++ sont tout sauf simple dès que tu commence à jouer avec les contraintes.

Ensuite pour ce qui est de :

Code:

---

1 2	class Exemple<T> where T: IUneInterface

---

Code:

---

1 2 3 4 5 6 7 8 9 10

class Exemple { private IUneInterface _membre;   public Exemple(IUneInterface param) { _membre = param; } }

---

Il est évident que la généricité ici ne sert à rien, cependant elle devient utile, si tu indique plusieurs interfaces dans tes contraintes pour T.

Quand à indiquer dans les contraintes que les types T manipulés doivent impérativement surcharger les opérateurs en précisant lesquels, c'est vrai que c'est fort domage que ce ne soit possible. Cependant en C++ c'est possible sans imposer de contrainte sur les types T utilisé. Lors de la compilation, il vérifie qu'il dispose de renseignement sur les opérateurs entre les types que tu paramètre.
(rappel, ces renseignements pouvant être définis dans les types que tu manipule en paramètre, ou ailleurs, vu qu'en C++ il est tout a fait possible de faire une horreur du genre

Code:

---

1 2 3 4 5

class ExempleElement { <div style="margin-left:40px"> ... friend static ExempleElement& operator +(ExempleElement& A, ExempleElement& B);</div>}

---

Sachant que dans le code, cet opérateur sera défini comme suite

Code:

---

1 2 3

ExempleElement& operator +(ExempleElement& A, ExempleElement& B) { <div style="margin-left:40px">...</div>}

---

Un mécanisme peut etre pas aussi "libéraliste" serait néanmoins souhaitable.
Car actuellement il n'est pas possible de définir des opérateurs pour les enumérations par exemples, ni pour le cast/boxing, ni pour autre chose si ce n'est l'égalité et l'inégalité.