Discussion :

[Guulh]

Non tu aurais une méthode du type :

Code :

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

void Button1_Click(Button sender, EventArgs e) {}

et donc un cast en moins à faire sur le sender. C'est peu de chose et ça ne vaut certainement pas le coup de changer tous les contrôles du framework 2 pour cela, mais si ça avait été implémenté depuis le début, ça aurait été agréable.

Ok, je vois mieux. Mais du coup, tu pourrais pas plugger plusieurs events de plusieurs contrôles sur une même méthode. Par exemple, j'ai des ToolStripButton et des Button qui ont une même fonction abonnée à leur Click.

Ce qui est vrai, par contre, c'est que les winforms ne tiennent absolument pas compte des generics. Mais comme je le disais hier, je ne sais pas dans quelle mesure generics et binding peuvent faire bon ménage. Par exemple, si on avait une Datagridview<T>, ça voudrait dire qu'elle ne pourrait contenir qu'un seul type d'objet (alors que aujourd'hui, comme elle n'est pas typée, elle peut contenir n'importe quoi) ; on ne pourrait pas non plus la plugger sur une datatable.

En tous cas, voilà ce qu'en dit le concepteur de C# : http://www.artima.com/intv/generics.html En résumé :

C# generics are really just like classes, except they have a type parameter. C++ templates are really just like macros, except they look like classes.

n étant inconnu, comment le compilateur peut calculer sa factorielle ?

Ca ne marche bien sûr que si n est défini à la compilation.

[maa]

Mais du coup, tu pourrais pas plugger plusieurs events de plusieurs contrôles sur une même méthode. Par exemple, j'ai des ToolStripButton et des Button qui ont une même fonction abonnée à leur Click.

On pourrait abonner les méthodes à l'événement Click du premier ancêtre commun. Mais j'y pense... le masquage de l'événement pour boutton ne fonctionnerait pas car cet événement est certainement appelé depuis une méthode OnClick d'une classe de base. Il faudrait alors quelque chose en plus aux génériques il me semble. Il faudrait qu'on puisse dire dans la classe de base.

public event EventHandler<TInherited, EventArgs> Click;

où TInherited désigne toujours le type de la classe héritée que l'on utilise effectivement.

Comme ça il n'y aurait pas besoin de masquer les événements Click dans les classes héritées. Ça serait faisable ?

Ce qui est vrai, par contre, c'est que les winforms ne tiennent absolument pas compte des generics. Mais comme je le disais hier, je ne sais pas dans quelle mesure generics et binding peuvent faire bon ménage. Par exemple, si on avait une Datagridview<T>, ça voudrait dire qu'elle ne pourrait contenir qu'un seul type d'objet (alors que aujourd'hui, comme elle n'est pas typée, elle peut contenir n'importe quoi) ; on ne pourrait pas non plus la plugger sur une datatable.

Je m'interesse plutôt au binding avec WPF maintenant. Il me semble d'ailleurs qu'on ne peut pas créer de contrôles génériques en WPF. Concernant ta bindinglist rien n'empêcherait de faire Datagridview<object> si tu en as besoin mais avec les génériques tu pourrais restreindre autant que tu veux le type des objets. Je ne sais pas si ça présentrait un réel avantage. Je pensais plutôt aux vue de collections qui ne sont actuellement pas typés. Je pense par exemple à la classe CollectionView qui pourrait être générique.
Je ne connais pas bien les mécanismes interne du Databinding et il y a peut être un raison à cela. Mais j'ai l'impression que quelque chese de mieux aurait put être fait.

Merci beaucoup pour le lien du concepteur de C#. Je vais le lire. Ça m'interesse beaucoup.