octobre
2008
Un article de Louis-Guillaume Morand
Speaker Anders Hejlsberg
Anders Hejlsberg est un programmeur danois. En 1980 il a commencé à écrire des programmes pour le micro-ordinateur Nascom ; il a en particulier écrit un compilateur Pascal qui a été vendu sous le nom de Blue Label Pascal compiler pour le Nascom-2. Il l’a rapidement réécrit pour CP/M et MS-DOS, et distribué sous le nom de Compass Pascal puis de Poly Pascal.
Après avoir été acquis par Borland, il a été distribué sous le nom Turbo Pascal.
Le rachat par Borland de son logiciel a amené Hejlsberg à être un des fondateurs de la société Borland dans laquelle il est resté jusqu’en 1996.
Il y a continué le développement du Turbo Pascal et est devenu chef de projet lors de l’élaboration du langage Delphi, successeur du Turbo Pascal.
En 1996 il a quitté Borland pour rejoindre Microsoft où il a travaillé sur le langage J++ et les Windows Foundation Classes. Il est le concepteur du Framework .NET.
Il dirige aujourd’hui l’équipe qui a créé le C#!!!
source: wikipedia (oui il a même sa page sur wikipedia, c’est vous dire 
cette session est la plus attendue de toutes et c’est la deuxième fois qu’elle a lieu en deux jours, et la salle est une fois de plus comble. Si vous voulez savoir pourquoi tant de personne assistent à cette conférence, alors lisez la suite…
Le titre qu’il se donne est d’être un simple geek technique (Technical fellow) et c’est pourtant lui qui décide ce que sera le C# de demain. Voyons ce qu’il nous a mijoté:
Historique de C#
=> C# 1.0 en code managé (commencé vers 97/98)
=> C# 2.0 était surtout dédié aux génériques
=> C# 3.0 Language Integrated Query (LINQ) /!\ on parle de C# 3.0 et pas du framework 3.0
=> C# 4.0 ???
Passons aux nouveautés
DynamicallyTyped Objets
Jusqu’à maintenant, vous aviez un code de ce style:
int sum = calc.Add(10,20);
Si vous vouliez faire la même chose avec la reflection, il fallait faire des des GetType() et/ou des InvokeMember et cela prenait beaucoup plus de lignes lignes.
maintenant, vous aurez simplement
int sum = calc.Add(10,20);
Nous pouvons donc voir l’apparition d’un nouveau mot-clé : Dynamic
un autre exemple de son utilisation
dynamic y = "Hello";
dynamic z = new List<int>{1, 2, 3];
A première vue, cela nous rappelle déjà quelque chose que l’on a. Continuons un peu plus loin
Comparons les deux codes suivants:
double y = Math.Abs(x);
et
dynamic y= Math.Abs(x);
Cela semble pareil à part un mot-clé qui change? Détrompez-vous!
La différence est que X à l’exécution pourra être de type Int32 par exemple, et donc la méthode Abs appelée, toujours à l’exécution, ne sera pas la même que lorsque x vaudra 1.75. ainsi, la différence est bien sûr ce point précis, à savoir, le mot-clé dynamic est utilisé à l’éxécution et non pas à la compilation comme les autres mots-clés. Cela permet de se moquer des tests de signature car le runtime saura quelle méthode est la plus adaptée
Attention, dynamic, comme le mot var ne devra pas être utilisé à toutes les sauces et déjà beaucoup de développeurs grincent des dents car cela permettra à des « mauvais développeurs d’écrire du mauvais code » exemple: http://stackoverflow.com/questions/245318/c4-dynamic-keyword-why-not#245537
et enfin, l’interface IDynamicObject vous permettra de créer vos propres objets dynamiques. Nous en saurons sûrement plus dans un futur proche.
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 …