octobre
2008
Un article de Louis-Guillaume Morand
d’autres nouveautés concernant la variance (co-variance et contra-variance) ou encore « Compiler as a service », qui grâce à l’objet CSharpEvaluator, va vous permettre d’accéder au compilateur et ce, à l’éxecution.
Ainsi, vous pourrez écrire
CSharpEvaluator c = new CSharpEvaluator();
c.Using.Add(« System »); // on ajoute les usings à la volée
c.Eval(« for (int i = 0;i <10;i++) Console.WriteLine( « Hello »+i); »);
ce qui évaluera, compilera et éxécutera le code à l’éxécution. Je suis impressionné par la fonctionnalité mais un peu dubitatif sur les failles que cela pourrait engendrer. Imaginez une application qui construit le code à la volée par exemple, à l’aide d’entrée utilisateur. Un peu comme le SQL Injection, ne serait-il pas possible d’injecter du code malicieux? Bon c’est un peu tiré par les cheveux mais je pense que c’est possible.
pour conclure:
Session IMPRESSIONNANTE. bien que l’on sache qu’ils sont super sélectionnés sur leurs compétences chez Microsoft, on se demande comment les mecs de l’équipe de C# arrive à avoir de telles idées et surtout comment ils font pour les mettre en pratique pour que nous, modestes développeurs, puissions développer plus simplement.
J’ai pas eu le temps de toucher à tout sur le C# 3.0 que déjà le 4.0 me donne envie 
Comme bien sûr il est difficile de résumer à sa juste valeur une session de ce style, je vous donne le lien pour voir
la session: http://channel9.msdn.com/pdc2008/TL16/
Pour les raisons qui ont déjà été données, je suis aussi très sceptique envers les paramètres nommés.
En tant que débutant en C# (pour Windows Mobile et depuis selement 2 mois, je viens du C++ et de Java) , et dans la mesure où ma remarque n’est pas le fruit de mon ignorance, je m’étonne de ne pas trouver les « features » suivantes :
– La ‘redéfinition’ des types de bases (comme en Pascal) qui vous permet de redéfinir par example des float comme des [mètre] ou des [seconde], ce qui vous évite de « additionner des choux et des pâtées » comme on dit, et qui rend le code plus lisible. (Mais est-ce faisable sans créer des classes cachées ? Quand on programme pour Windows Mobile, on doit quand même faire attention à la place mémoire)
– de ne pas avoir ajouté en « natif » (sans devoir faire des classes ad-hoc) des types avec unités, qui vous permettent par example de faire des opérations entre des [km], des [m] et de [mm] sans se coltiner des facteurs 1000 sans cesse (et donc de les oublier de temps à autre)
Ceci dit, de ma maigre expérience, je préfère C# à Java (et je haïs cette horreur de C++)
Pour ce qui est du mot clef dynamic, l’équivalent « à la main » est deja réalisable, genre :
Avant C# 3.0 :
object foo = …
foo.GetType().GetMethod(« MyMethod »).Invoke(foo, new Object() { Params });
Depuis C# 3.0, avec les fonctions extension :
public static object Invoke ( this object instance, string name, params object[] arguments )
{
return instance.GetType().GetMethod(name).Invoke(instance, arguments);
}
…
foo.Invoke ( « MyMethod », new Object() { Params } );
Pour ce qui est de l’évaluation à l’execution du code C# c’est deja faisable depuis la version 1.0 de C# (si je me trompe pas), en utilisant le namespace classe System.ComDom.Compiler et ses accolytes, avec un peu de travail autour (15/20 lignes d’appels).
En tout cas c’est sympa que ce genre de fonctionnalités rentre dans le language, mais ces deux la ne révolutionnent rien…
je l’ai pas compris non plus
il manque la suite. faut que tu réussisses à trouver le whitepaper des specs C4 4.0, c’est plus détaillé mais pas bcp plus clair
LGM : Pour la covariance/contravariance je n’ai pas vraiment compris ton exemple.
En Java on a une notion de covariance sur le type de retour d’une méthode. Cela permet de remplacer le type de retour d’une méthode par un type plus spécifique, à condition qu’il soit bien un type enfant du type précédemment utilisé.
Par exemple si on redéfini une methode qui retourne un Number, on peut changer son type de retour dans la classe fille et déclarer un Integer par exemple.
Pour la contravariance cela n’existe pas dans Java mais on en a parlé pour la notion de closure, et cela permet d’affecter des méthodes à des closures qui ne prennent pas exactement les mêmes types de paramètres, à partir du moment où cela est compatible. En gros on pourrait utiliser toutes les méthodes dont les paramètres correspondent au type exact ou à un type fils de celui de la closure…
Je ne sais pas si je suis bien clair…
a++
désolé laurent, j’ai donné toutes les infos que j’ai pu avoir et j’en ai même rajouté quelques unes trouvées dans le white paper des previews de C#4. La seule chose que je maitrise pas encore c’est covariance et contravariance et les in/out. pas sûr d’avoir compris leur intérêt
« on se demande comment les mecs de l’équipe de C# arrive à avoir de telles idées »
Je pense qu’il y en a quelques une qui ont été énoncés par d’autres, Bertrand Meyer (covariance), et l’équipe regardent ce que font les autres (Java par exemple).
Les utilisateurs aussi énoncent des besoins ou des demandes d’améliorations pertinentes.
Ensuite la qualité de l’équipe fait le « reste », et même d’améliorer de bonnes idées préexistantes ce n’est effectivement pas permis à tout le monde.
Puisque MS dépose des brevets pour tout ce qu’il font, ce serait intéressant de consulter ceux relatif à C#.
De mon coté je suis un peu surpris de ne pas retrouver quelques évolutions proposées dans Spec#, la programmation par contrat, c’eût été plus appréciable que la notation nommée de paramètres qui existe déjà depuis un bout de temps dans d’autres langages, en PL/SQL par exemple
Dans le graphique de la première page il est fait mention de la DLR mais qu’en est-il de la CLR ?
Est-ce que c’est un annule/remplace ou restera-t-il possible de choisir ?
« Attention, dynamic, comme le mot var ne devra pas être utilisé à toutes les sauces »
Certes mais une fois qu’on y gouté, on se demande comment on a pu faire sans !
Bruce Payette, un des concepteurs de PowerShell, associe le dynamisme d’un langage avec la méta-programmation…
Il serait bon de savoir ce que MS entend par dynamisme dans le C#, plus précisément quels ont été leurs objectifs.
Et par hasard, aurais-tu quelques infos sur un possible portage de PowerShell sous la DLR ?
Ton post est très intéressant et donne envie d’en savoir plus.
@zedros : Oui on est d’accord
@Louis-Guillaume Morand : clairement, nous sommes d’accord pour la reprise d’idées, il n’y a aucun mal, au contraire. Seul hic au demeurant : un langage peut difficilement faire retour arrière, d’où l’importance de ce qu’on reprend et comment…
Concernant le post, je me demandais juste s’il y avait des « nouveautés jamais vues ».
@adiGuba : pour les développeurs « lambda » oui, mais il me semble que cela peut être bien intéressant pour les développeurs de framework et/ou outils non ? Je pense notamment à cglib.
++
Heu… j’ai peut-être mal compris mais ce que tu appelles « compilateur en tant que service » c’est bien le fait de compiler et d’exécuter du code à la volée ?
Alors c’était déjà possible en Java depuis longtemps via des API non-standard (en utilisant la librairie tools.jar de Sun par exemple), et cela a été standardisé depuis Java 6 via Java Compiler API
Par contre pour la plupart des développeurs cela n’a pas vraiment une grande utilité…
a++
bien sûr qu’ils ont pompé en partie, encore faut-il réussir à le mettre en place sur leur archi. pour le compilateur en tant que service, je connais pas de langage le faisant, même si ca doit bien exister. En tout cas, il n’y pas de mal à piquer le meilleur d’un autre langage, JAVA est né comme ca, il en a été de même pour C#
Ce genre de danger (pour les attributs optionnels) m’inquiète toujours un peu, surtout en maintenance :
/! il reste un problème. que se passe-t-il si une forme de signature avec un paramètre omis correspond à deux méthodes possibles? Et bien tout simplement, il ira choisir la méthode sans les paramètres optionnels. Faites bien attention à cela.
Le compilateur génère t il un warning lorsqu’il détecte de tels cas ? Cela ne pourrait pas être tout simplement interdit/une erreur ?
Par contre pour les superbes idées de l’équipe C#, cela reste quand même, pour l’essentiel, des idées flottant déjà par ailleurs non ? Où ai je raté une réelle innovation d’un point de vue « informatique » ?
Merci bien pour ce post fort instructif.
++
Le problème ne vient pas vraiment de la fonctionnalité mais plutôt de son intégration dans des langages comme Java/C# où la compatibilité doit être préservé au maximum…
a++
j’avais pas pensé à cela, et effectivement, tu perds la possibilité de faire évoluer uniquement les assemblies que tu déploies. Merci pour ta remarque, j’aurais dû le dire au speaker : »hey msieur, ca pue ton truc
»
LGM : Dans ton code oui sûrement, mais pas si tu développes une librairie utilisée par d’autre…
J’avais vu ce problème signalé en ce qui concerne des discussions similaires sur Java.
Voici un cas de figure : Tu développes une librairie quelconque. Puis une fois qu’une version a été déployée tu la fais évoluer pour diverses raisons (corrections de bugs, évolutions, etc.). Là tu t’aperçois tu n’as pas toujours bien choisit tes noms de paramètres, et tu voudrais corriger cela. Par exemple tu as ceci :
Et tu te dis que ce serait quand même mieux d’avoir ceci :
Malheureusement cette modif apparemment sans conséquences risque de gêner les développeurs qui utilise ta librairie s’ils ont utilisé les paramètres nommées, car ce code ne compilerait plus :
A cause de cela ils ne pourront pas utiliser ta nouvelle version sans retoucher leurs codes => cela casse la compatibilité des sources !
Des problèmes similaires se posent lorsqu’on veut renommer une méthode, mais là on peut laisser l’ancienne méthode en « deprecated » (je ne sais pas si c’est le même terme en C#).
Avec les paramètres nommées on est obligé de conserver les noms si l’on souhaite conserver la compatibilité des sources.
Je te l’accorde ce n’est pas un problème primordial mais cela en est un : en donnant de l’importance aux noms des paramètres, on restreint la possibilité de les renommer.
a++
@adi : le renommage automatique de Visual (btn droit > renommer) ne devrait-il pas permettre que ce ne soit pas un problème?
Salut,
Une remarque pour les paramètres nommées, : cela apporte une nouvelle source d’incompatibilité potentielle au niveau des sources, car cela implique que les paramètres des méthodes d’une librairies ne soient jamais changés ! Le moindre changement du nom d’un paramètre provoquerait une erreur de compilation lorsqu’on utilise les paramètres nommées…
a++
Pour ce qui est de l’évaluation du code à la volé avec le CSharpEvaluator, Mono l’a déjà :aie:
Sinon je suis très très prudent par rapport au mot clef dynamics …