Discussion :

[maa]

Bonjour,

L'arrivée du framework 2.0 a rendue pas mal de classes obsolètes principalement à cause des generics. On peut regretter que les generics n'ai pas étés présents dans la version 1 car à présent ces classes obsolètes seront présentes dans toutes les versions futures pour assurer la compatibilité. Mais pire, j'ai l'impression que les choses auraient étés mieux conçues si les génériques avaient étés là dès le début.
N'aurait-on ainsi pas pu éviter des interfaces comme ICollection, IList, IEnumerable, IBindingList pour n'utiliser que leurs équivalents génériques ?
Il me semble également que beaucoup de classes, méthodes, délégués sont encore dépourvues de type paramètres. S'agit-il encore d'un héritage du framework 1 ? Je suis par exemple toujours étonné que la méthode abonnée au clique d'un bouton ait son premier paramètre de type object alors qu'on sait que c'est un bouton !
Aurait-on eu un framework mieux pensé, plus typé et plus légers si les generics avaient été implémentés dès le début ? Ou l'étape "framework 1" était elle nécessaire ?

Merci d'avance pour toutes vos remarques sur le sujet.

mathmax

[Louis-Guillaume Morand]

ta réflexion se résume à
n'aurait-on pas dû sortir JAVA 1.5 directement pour implémenter les generics? on aurait gagné 20ans.
n'aurait-on pas dû sortir directement Windows Seven, on aurait évité Winfows millenium
Ne devrait-on pas arrêter de vendre des voitures à essence et attendre des voitures à piles nucleaire?

ta reflexion n'est pas bête mais n'est pas pour autant logique, elle pense trop "carré". Oui c'est beau les generics, mais si tu repousses tjs la sortie d'un produit quelconque, sous pretexte qu'une nouveauté arrive derriere, alors ton produit sort jamais, et tu aurais dis, pourquoi ne pas avoir sorti LINQ Directement. Tu crois que parce que le fx 2.0 est sorti 2ans apres le 1.1 alors on aurait pu attendre deux ans? nana, le developpement framework a commencé BIEN des années plus tôt et on ne peut pas tout prévoir à l'avance. Windows Vista a commencé à être développé AVANT la sortie d'XP, la R&D d'un os ou d'un langage est bien compliqué qu'il n'y parait surtout que le principe de MSIL et de mult langages au dessus, etc était tout nouveau
le framework aurait sûrement une autre forme mais il n'en est pas moins très bien pensé pour la cible qu'ils voulaient faire à l'époque. vaut mieux réflechir à qu'est ce que toi tu pourrais developper et mettre sur codeplex pour le rentre plus complet, plutot que se demander ce qu'aurait sa tronche si les generics étaient presents dès le début, par le clic d'un bouton, que t'aies object ou T, dans ce cas là, ca change pas grand chose

voilà mon avis

[anthyme]

C'est vrai que maintenant c'est un peu le bordel l'absence de generic sur les vielles classes du framework ... plus certains autres trucs...

Moi j'aurais préféré que la 2.0 sorte directement car c'est évidant que certaine chose "malpropre" aujourd'hui n'existerait pas ... mais je peux comprendre qu'une boite qui doit "gagner de l'argent" sorte la 1.0 qui permettait déjà pas mal de truc...

[Louis-Guillaume Morand]

Microsoft n'a pas sorti le framework .Net pour se faire de l'argent. elle ne gagne pas plus d'argent que lorsqu'on utilisait win32. pourquoi toujours rapporter MS =$$?
M£ gagne moins de thunes avec .Net que google avec son moteur de recherche et on ne dit rien

[anthyme]

Euuuh tout entreprise qui entreprend quelque chose le fait pour de l'argent... car le but d'une entreprise est de se faire de l'argent ...

.Net ne se vend pas certes... mais donne un socle de développement commun de plus haut niveau que win32 permettant de créer des applications très lié à windows.

Un exemple de revenu apporté par .net : une entreprise fait un site internet e-commerce en asp.net donc elle l'installe sur un windows server... Si l'application était fait en PHP ou Java, est ce que tu pense qu'il aurait acheter une licence windows server ?

Voila ce sont des revenus indirect mais pourtant générer par la création (et l'amélioration continue) du framework .net

je pense que .net est une réponse à la portabilité de java qui entrainait trop de développement sur des plateforme non windows.

Après je vois pas pourquoi il faudrait se braquer lorsqu'une entreprise fait de l'argent... Une entreprise c'est fait pour gagner le plus d'argent possible avec le moins de dépense et de faire tout ce qui est possible (dans un cadre légal normalement ) pour s'en faire toujours plus

[SpiceGuid]

Oui c'est beau les generics, mais si tu repousses tjs la sortie d'un produit quelconque, sous pretexte qu'une nouveauté arrive derriere, alors ton produit sort jamais, et tu aurais dis, pourquoi ne pas avoir sorti LINQ Directement.

.Net, vous avez à peine le temps de découvrir la généricité que F# vous offre déjà le polymorphisme paramétrique (à l'ordre 1 ou à l'ordre 2 ?), bande de veinards, Microsoft.

Sauf que, du coup, en comparaison, la généricité toute bête risque de vous paraître un peu tristounette.

[Louis-Guillaume Morand]

je me braque pas et tu as raison pour asp.Net et serveur et tu peux aussi dire qu'une appli winform force l'utilisation de Windows donc l'achat de licence, pourtant il faut aussi savoir que l'idée principale était de l'utiliser en interne et que c'est par la suite, qu'ils ont décider de le partager. Je dis pas qu'ils ne se font pas d'argent dessus, simplement, le fait de sortir une version 1.0 sans generics n'a strictement aucun rapport avec l'argent, d'où ma remarque pour ne pas dériver sur ce point alors que le débat est intéressant

[maa]

Oui c'est beau les generics, mais si tu repousses tjs la sortie d'un produit quelconque, sous pretexte qu'une nouveauté arrive derriere, alors ton produit sort jamais, et tu aurais dis, pourquoi ne pas avoir sorti LINQ Directement.

Je trouve que le cas de linq est différent. Son implémentation ne remet pas beaucoup de choses en cause. En revanche les génériques auraient pu être implémentés dans tant de classes et la hierrarchie des collections aurait put être vu de façon totalement différente.

Par exemple, vous trouvez ça normal ?

Code :

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

1
2
3
4
 
 
    public class BindingList<T> : Collection<T>, IBindingList, IList, ICollection, IEnumerable, ICancelAddNew, IRaiseItemChangedEvents
{ ...}

BindingList<T> n'implémente ni IList<T>, ni IEnumerable<T> et quand à IBindingList<T> elle n'existe même pas.

Je peux comprendre le manque de temps pour sortir tout ça dans le framework 1, mais j'ai l'impression que ça aurait valu le coup de repousser un peu la sortie (pour la qualité du framework). Ils auraient par exemple pu penser à une implémentation à la JAVA dans un premier temps, c'est à dire pas de génériques dans le MSIL puis ajouter ceci dans le framework 2. Ca aurait été transparent pour le framework.

[anthyme]

Je dis pas qu'ils ne se font pas d'argent dessus, simplement, le fait de sortir une version 1.0 sans generics n'a strictement aucun rapport avec l'argent

Moi je vois cela avec un similitude de tous les projet qu'on fait sortir plus vite en "demi release" pour rentabiliser les investissements fait dessus et ne pas attendre d'avoir faire "tout ce qu'on a en tete" car "le temps presse", c'est hyper fréquent sur une majorité des produit Microsoft et fait qu'on doit souvent attendre la v2 pour avoir un truc chiadé

Le dernier exemple est Silverlight.

Sinon je vois pas où tu as vue que c'était un truc utilisé en interne et ("généreusement") "donné" au public, de ce que je me rappelle cela s'appelait Windows future services ou un truc dans ce style et avait pour but de créer un nouveau socle commun pour les applications développé pour windows...

Sinon je blâme pas ... au contraire j'apprécie car ça permet de se former sur les technos au début d'ailleurs la concurrence fait beaucoup ca mais sous d'autre forme comme google et ses betas

Mais de la a dire que .net est distribué sans aucun but économique entre la promotion de windows et VS je vois pas vraiment

[zoaax]

Si le framework 2.0 était sorti avant le framework 1.0, on n'aurait pas pu l'appeler 2.0
Mmh désolé pour cette remarque.

Ceci dit, je pense que si les fonctionnalités apportées par le framework 2.0 avait pu être intégrée dans le framework 1.0, il l'aurait fait. Je ne vois pas pourquoi il s'en serait privé. Il faut peut-être aussi considérer que la version des langages au moment de la sortie du 1.0 ne supportait pas toutes les fonctionnalités apportées par le framework 2.0.
Et puis comme l'a si bien dit Louis Guillaume Morand, il n'est pas possible d'attendre quelques années de sortir un produit juste parce qu'il serait possible d'en sortir un mieux.
C'est comme quand tu achètes un PC. Tu peux toujours attendre en te disant que dans quelques mois, tu auras plus puissant pour le même prix.

Certaines évolutions amènent d'autres évolutions et qui en amènent d'autres à leur tours, etc, etc.

++

[maa]

Évidemment chaque nouveauté rend obsolète des choses anciennes. C'est quelque chose de tout à fait normal. On ne peut pas avoir la perfection du premier coup. Mais il y a des éléments du langage qui permettent de concevoir un framework de façon de totalement différente. Je pense que c'est le cas des génériques.
Quand je vois les améliorations du framework 3 et 3.5, je n'ai pas du tout la même sensation :

- WPF remplace les Windows Form mais c'est seulement une partie du framework qui est remplacée. Et cette nouvelle partie se marie parfaitement avec le framework 2. Il n'y a pas de recollage fastidieux. Dans le cas des générique c'est un peu le contraire. On a remplacé certaines classes un peu partout en essayant des les intégrer le mieux possible avec ce qui existait déjà mais on ne l'a pas fait systématiquement de peur de revoir le framework de bout en bout.

- LINQ, est au même titre que les génériques une amélioration du langage. Certes il y est basée sur les méthodes d'extensions qui sont un peu de l'ordre du "recollage" pour les puristes, mais je trouve que son intégration est beaucoup mieux réussie que les génériques.

Maintenant l'idée que je voulais débattre c'était plutôt d'imaginer comment serait le framework si il avait été conçu dès le début avec les génériques.

[Guulh]

BindingList<T> n'implémente ni IList<T>, ni IEnumerable<T> et quand à IBindingList<T> elle n'existe même pas.

Euh... BindingList<T> hérite de Collection<T> qui implémente ces interfaces... Et IBindingList<T> servirait à rien (à mon avis) : l'idée du binding, c'est de se baser sur la réflexion, et la DGV par exemple aurait beau connaître le type T des éléments de sa source, elle saurait pas quoi faire de cette info.
Après, on pourrait envisager des Control<T>. mais je sais pas ce que ça permettrait d'écrire plus élégamment.

Quand au sujet principal de ce thread, les concepteurs de C# reconnaissaient dans une interview (j'ai plus le lien, désolé )qu'ils auraient aimé mettre les generics dès le début, mais qu'ils ont du patienter pour des raisons de planning.

Pour ce qui est de tes remarques sur le système d'événements (avec les OnBidule(object sender, MachinEventArgs e), je vois pas le rapport avec les Generics.

Quand j'ai commencé C#, on en était déjà au FX2, et je ne ressens pas spécialement que les generics soient une greffe difficile sur un FX existant. Je crois pas que le fx aurait été si différent si ils avaient été présents dès le début.

[davcha]

Maintenant l'idée que je voulais débattre c'était plutôt d'imaginer comment serait le framework si il avait été conçu dès le début avec les génériques.

Si c'était le cas, tu n'aurais peut-être pas besoin de Postsharp à l'heure actuelle, car Microsoft aurait peut-être fait un framework 2.0 avec des templates...

Mais du coup, nous demanderais-tu comment serait le framework s'il avait été conçu dès le départ avec des templates... ?

[Philippe Vialatte]

Tiens, c'est marrant, j'ai lu ca il y'a 2 jours

http://www.computerworld.com.au/inde...6074;fp;;fpid;

Page 3 de l'article :

Would you do anything differently in developing C# if you had the chance?

There are several things. First of all, when we shipped C# 1.0 we did not have generics in the language – that came in C# 2.0, and the minute we shipped generics we were able to put a lot of old code to bed as it was superfluous and not as strongly typed as generics. So a bunch of stuff got deprecated right out of the box in C#2.0. We knew generics were coming but it was one of those hard decisions: do you hold the platform longer or do you ship now and work on this and then ship it a couple of years later? I would have loved to have generics from the beginning as it would have left us with less obsolete stuff in the framework today.

[maa]

Si c'était le cas, tu n'aurais peut-être pas besoin de Postsharp à l'heure actuelle, car Microsoft aurait peut-être fait un framework 2.0 avec des templates...

Mais du coup, nous demanderais-tu comment serait le framework s'il avait été conçu dès le départ avec des templates... ?

En fait je ne connais pas très bien le mécanisme des templates car je ne connais pas le C++. A la lecture de ton post, je me suis un peu renseigné sur les templates mais je n'arrive pas encore bien à saisir la différence avec les génériques à part le fait qu'ils sont traités à la compilation et qu'il génèrent autant de méthodes que de types génériques fermés. Pourrais-tu m'expliquer pourquoi ils permettraient de se passer de PostSharp ?
L'implémentation de postsharp ou d'un mécanisme similaire dans le framework serait très bien mais est-ce que ça remettrait tant en cause à la structure de ce dernier ? J'ai du mal à me l'imaginer... peut être que oui.

Euh... BindingList<T> hérite de Collection<T> qui implémente ces interfaces...

Euh oui très juste... mais il reste quand même la moitié des interfaces qui sont inutiles : toutes celles qui ne sont pas génériques. Ca fait quand même un paquet d'implémentation pour une collection. Bon ça reste des interfaces...

Et IBindingList<T> servirait à rien (à mon avis) : l'idée du binding, c'est de se baser sur la réflexion, et la DGV par exemple aurait beau connaître le type T des éléments de sa source, elle saurait pas quoi faire de cette info.

Il me semble que le binding se base sur le typeDescriptor et non la réflexion. Or ce dernier, de même que les classes propertyDescriptor, FieldDescriptor,... auraient put être génériques. Cela aurait par exemple permit de créer des vues génériques d'objets et de collections.

Pour ce qui est de tes remarques sur le système d'événements (avec les OnBidule(object sender, MachinEventArgs e), je vois pas le rapport avec les Generics.

Il pourrait exister une classe EventHandler<TSender, TEventArgs>. Dans le cas de bouton on aurait :

Code :

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

public event  EventHandler<Button, EventArgs> Click;

Bon cet événement existe également dans la classe Control. Mais quel serait l'inconvénient de le masquer pour chaque classe dérivée ?

[davcha]

Les templates c++ tiennent plus du générateur de code que des generics c#.

[maa]

Que permettent t-ils de faire de plus que les generics ?

[Guulh]

Code :

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

public event  EventHandler<Button, EventArgs> Click;

Et ça changerait quoi ? Tu aurais une méthode OnTruc<T>(T sender, EventArgs e), et ça t'avancerait à quoi ? (ce n'est pas une question rhétorique ni moqueuse, je voudrais juste voir si je rate qq chose )

Entre autres, avec les templates C++, si t'as par exemple une fonction f<T>, tu peux définir une implémentation par type, si tu veux. En pseudo code :

Code :

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

1
2
3
4
 
string f<T>() { return "type inconnu"; }
string f<int>() { return "int"; }
string f<UneClasse>() { return "bob"; }

Chose impossible avec les generics C#. En gros, c'est des macros au niveau des classes.

[davcha]

Que permettent t-ils de faire de plus que les generics ?

En (très) gros, les generics c# te permettent de définir une méthode paramétrée par un type de donnée.
Donc tu peux écrire des choses comme T Machin<T,U>(T truc,U bidule); mais T et U restent des types et seront utilisés pour typer des variables dans ta classe/méthode.

Les templates C++, de la même manière, te permettent de définir une méthode paramétrée par n'importe quoi.
C'est là l'une des différences importantes.
Tu peux écrire des choses comme : template<int n> int Factorielle<n>(); qui calculera la factorielle de n à la compilation.
L'exemple est vraiment très (trop) simple pour qu'on puisse réellement voir l'intérêt du truc, évidemment.

[maa]

Et ça changerait quoi ? Tu aurais une méthode OnTruc<T>(T sender, EventArgs e), et ça t'avancerait à quoi ? (ce n'est pas une question rhétorique ni moqueuse, je voudrais juste voir si je rate qq chose )

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.

Tu peux écrire des choses comme : template<int n> int Factorielle<n>(); qui calculera la factorielle de n à la compilation.

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

Pourquoi les templates n'ont pas été implémentés en c# ? Leur ajout est-il prévu pour une version future ?