Ceci dit, de ma maigre expérience, je préfère C# à Java (et je haïs cette horreur de C++)

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…

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++

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.

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.

++

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++