Tour d'horizon des nouveautés de C# 4.0

* Slide provenant de la présentation « The Future of C# » de Anders Hejlsberg lors de la Microsoft PDC 2008

Comme vous l'avez compris depuis un moment à présent, la résolution des objets dynamiques se fait au moment de l'exécution, mais il faut savoir que cette résolution va être différente selon le type de l'objet dynamique. Il existe en fait trois types d'objets :

• les objets COM, l'opération est dispatchée dynamiquement à l'interface IDispatch de l'objet COM en question ;
• les objets dynamiques, ce sont des objets qui implémentent la nouvelle interface IDynamicObject et dans ce cas, c'est l'objet lui-même qui va s'occuper de résoudre l'opération. En implémentant cette interface dans nos classes, on va pouvoir personnaliser complètement leur comportement lors de leur utilisation sous forme d'objets dynamiques ;
• les objets simples, c'est tout simplement les objets .NET dont les opérations seront transformées en appels utilisant la réflexion avec utilisation d'un « runtime binder » comme vous pouvez le voir sur le précédent schéma.

Rien de tout cela ne serait possible sans la « Dynamic Language Runtime » qui est une nouvelle API du Framework .NET 4.0 permettant les appels dynamiques.

Cette API est en fait une surcouche de la CLR (Common Language Runtime) et permet de faciliter l'implémentation et l'interopérabilité des langages dynamiques avec la plateforme.NET, les plus connus sont IronPyhton et IronRuby.

Pour en savoir plus sur la DLR, je vous invite à consulter la fiche Wikipedia : http://en.wikipedia.org/wiki/Dynamic_Language_Runtime

Pour déclarer un paramètre d'une méthode comme optionnel, il suffit tout simplement de lui affecter une valeur par défaut :

public static void MaMethode(string s, int i = 10, bool b = false)
{
    Console.WriteLine("s = {0}, i = {1}, b = {2}", s, i, b);
}

Et pour appeler cette méthode, je pourrais omettre le second ou le troisième paramètre si je le désire :

MaMethode("Hello");
MaMethode("Hello", 5);
MaMethode("Hello", 5, true);

// MaMethode("Hello", false); // Interdit

Ce qui donnera à l'exécution :

Au passage, vous remarquez que je ne peux pas omettre le second paramètre tout en précisant le troisième pour la bonne et simple raison que les paramètres qui sont laissés optionnels doivent tous se trouver après le dernier paramètre spécifié.

Pour spécifier un paramètre nommé, il suffit lors de l'appel de la méthode de préciser le nom du paramètre suivi de « : » puis la valeur du paramètre. Ainsi, on va pouvoir spécifier les paramètres dans l'ordre que l'on désire.

MaMethode("Hello", 5, b: true);
MaMethode(s: "Hello", i: 5, b: true);
MaMethode(b: true, i: 5, s: "Hello");

// MaMethode(s: "Hello", 5, b: true); // Interdit

Dans le cas où on désire utiliser des paramètres non nommés avec des paramètres nommés, ces derniers doivent toujours se trouver en dernières positions.

À savoir aussi que les paramètres optionnels et les paramètres nommés peuvent non seulement être utilisés avec les méthodes, mais aussi avec les constructeurs et les indexeurs.

Prenons un exemple tout simple qui est la création d'une feuille Excel dans laquelle on va écrire du texte dans une cellule.

var excel = new Microsoft.Office.Interop.Excel.Application();

((Microsoft.Office.Interop.Excel..Range)excel.Cells[1, 1]).Value2 = "Ma feuille Excel";

Le problème est qu'on est sans cesse obligé de convertir les objets. Dans l'exemple précédent l'accès à l'indexeur renvoie un objet, mais moi en tant que développeur, je sais que l'objet renvoyé est évidemment de type « Excel.Range ». Et bien aujourd'hui, c'est fini ! Avec C# 4.0, vous pourrez dorénavant écrire :

var excel = new Microsoft.Office.Interop.Excel.Application();

excel.Cells[1, 1].Value2 = "Ma feuille Excel";

En fait, nous avons déjà parlé de cette nouvelle fonctionnalité, c'est le principe de la programmation dynamique. Le compilateur considère que « excel.Cells[.] » renvoie un type dynamique, donc libre à vous d'accéder aux propriétés et méthodes que vous désirez et ce n'est que lors de l'exécution que la résolution sera effectuée :

• J'ai un type dynamique - « excel.Cells[1, 1] »
• Auquel je dois vérifier s'il existe une propriété nommée « Value2 » de type string avec un accesseur « set » - « Value2 = « Ma feuille Excel » »

Si vous avez l'habitude de développer en utilisant des objets COM, vous vous êtes sans conteste heurté aux paramètres de méthodes qui ne vous intéresseront jamais et pourtant, vous êtes obligé de passer une valeur par l'intermédiaire de « System.Type.Missing ». Si on prend le code permettant de créer une nouvelle feuille à notre classeur Excel sans vouloir spécifier sa position, on écrira tout simplement :

var excel = new Microsoft.Office.Interop.Excel.Application();

var newSheet = excel.Sheets.Add(System.Type.Missing, 
                                System.Type.Missing, 
                                System.Type.Missing, 
                                System.Type.Missing);

On remarquera que la méthode « Add » requiert quatre paramètres optionnels qu'il est obligatoire de préciser mêmes ci ces derniers ne nous intéressent pas.

Avec C# 4.0, le code deviendra tout simplement :

var excel = new Microsoft.Office.Interop.Excel.Application();

var newSheet = excel.Sheets.Add();

Mieux encore, si je désire créer cinq feuilles Excel en même temps, il suffit que je renseigne le troisième paramètre optionnel « Count » représentant le nombre de feuilles Excel que l'on désire créer. Ici je vais pouvoir tout simplement nommer mon paramètre comme on l'a déjà vu précédemment :

var excel = new Microsoft.Office.Interop.Excel.Application();

var newSheet = excel.Sheets.Add(Count: 5);

Une autre petite nouveauté est l'utilisation des paramètres passés par référence. De nombreuses méthodes d'objets COM nécessitent de passer les paramètres par référence alors que dans la plupart des cas, cela devrait être de simples paramètres valeurs. Tout cela oblige le développeur à créer une variable locale pour ensuite la passer en paramètre de la méthode précédé du modificateur « ref » permettant de passer une variable de type valeur par référence. Ce qui donne par exemple :

var word = new Microsoft.Office.Interop.Word.Application();

object missing = System.Type.Missing;
object visible = true;
word.Documents.Add(ref missing, ref missing, ref missing, ref visible);

Avec C# 4.0, il ne sera plus nécessaire d'utiliser « ref » et ainsi, on pourra écrire :

var word = new Microsoft.Office.Interop.Word.Application();

word.Documents.Add(System.Type.Missing, System.Type.Missing, System.Type.Missing, true);

En fait, c'est le compilateur qui s'occupera de créer pour vous une variable locale pour la passer ensuite par référence.

Avec C# 4.0, une nouvelle signification a été donnée au mot clé « out » dans le but de permettre la covariance avec les génériques.

interface IMembres<out T> { }
class Membres<T> : IMembres<T> { }
class Moderateur { }
class Responsable : Moderateur { }

class Program
{
    static void Main(string[] args)
    {
        IMembres<Responsable> responsables = new Membres<Responsable>();
        IMembres<Moderateur> moderateurs = responsables;
        IMembres<object> membres = responsables;
    }
}

Grâce à l'utilisation du mot clé « out » dans la déclaration de l'interface « IMembres », il est à présent possible de convertir un « IMembres<Responsable> » en « IMembres<Moderateur> » étant donné que la classe « Responsable » dérive de « Moderateur ». Ce système n'est donc utile que dans la position de sortie (output) des variables.

Cet exemple est similaire à l'interface « IEnumerable<T> » et pour cause, à partir du Framework .NET 4.0, cette interface sera étendue de la sorte :

public interface IEnumerable<out T> : IEnumerable
{
    IEnumerator<T> GetEnumerator();
}
public interface IEnumerator<out T> : IEnumerator
{
    bool MoveNext();
    T Current { get; }
}

Ainsi, on pourra envisager la conversion suivante :

List<string> mesStrings = new List<string>();
IEnumerable<object> mesObjects = mesStrings;

Contrairement à ce que j'ai pu lire sur certains blogs, ce système de covariance sur les génériques ne s'applique que sur les interfaces et délégués et pas (ou pas encore) aux classes et méthodes.

Une autre chose importante à préciser, la conversion dite de « boxing », c'est-à-dire la conversion d'un type valeur (int, float, double, char, les structures, etc.), n'est pas autorisée. Seule la conversion de référence est permise pour l'instant.

IEnumerable<object> mesObjects = IEnumerable<string>; // Conversion de référence autorisée
IEnumerable<object> mesObjects = IEnumerable<int>; // Boxing interdit

À l'inverse du mot clé out, nous avons le mot clé « in » qui va autoriser la contra variance au niveau des génériques. Ici on va pouvoir agir sur les paramètres d'entrées. Pour l'exemple suivant, je vais reprendre celui que propose l'équipe C# dans son document « New features in CSharp 4.0 », il me semble assez explicite :

public interface IComparer<in T>
{
    int Compare(T left, T right);
}

L'interface « IComparer » autorise la contra variance de « T » grâce au modificateur « in », ce qui signifie que si vous avez un « IComparer<object> », vous pourrez l'utiliser comme un « IComparer<string> ».

Un exemple d'utilisation ne sera pas de trop : prenons le cas de deux classes « MembreDvp » qui contient une propriété « Nom » et « ResponsableDvp » qui dérive de la classe « MembreDvp ». À ça, je vais créer une classe « myComparer » qui implémente l'interface « IComparer<MembreDvp> » pour faire une comparaison sur base de la propriété « Nom ». Ainsi, il va nous être possible de trier une liste de « MembreDvp » grâce à la propriété « Sort » de la classe « List<T> » qui prend en paramètre un IComparer. Mais imaginons que nous avons une liste de « ResponsableDvp » et que nous désirons la trier sur base du nom (propriété qui provient de la classe « MembreDvp » pour rappel), jusqu'à C# 3.0, il est impossible de réutiliser notre classe classe « myComparer » et la seule solution est de créer un autre classe qui implémente un « IComparer<ResponsableDvp> », admettez que dans notre cas, c'est du travail en trop et c'est tout à fait légitime. Rassurez-vous, avec C# 4.0, tout cela sera définitivement terminé comme démontré dans l'exemple suivant :

public class MembreDvp
{
    public string Nom { get; set; }
}

public class ResponsableDvp : MembreDvp
{ }

class myComparer : IComparer<MembreDvp>
{
    public int Compare(MembreDvp x, MembreDvp y)
    {
        if (x == null && y == null)
        {
            return 0;
        }
        else if (x == null)
        {
            return -1;
        }
        else if (y == null)
        {
            return 1;
        }
        else
        {
            return x.Nom.ToLower().CompareTo(y.Nom.ToLower());
        }
    }
}

class Program
{
    static void Main(string[] args)
    {
        myComparer comparer = new myComparer();

        List<MembreDvp> membresDvp = new List<MembreDvp>();
        membresDvp.Add(new MembreDvp() { Nom = "Thomas Lebrun" });
        membresDvp.Add(new MembreDvp() { Nom = "Skyounet" });
        membresDvp.Add(new MembreDvp() { Nom = "the_badger_man" });
        membresDvp.Add(new MembreDvp() { Nom = "Aspic" });
        membresDvp.Add(new MembreDvp() { Nom = "tomlev" });

        membresDvp.Sort(comparer);

        Console.WriteLine("Tri des membres Dvp");
        Console.WriteLine("*******************");
        foreach (var membre in membresDvp)
            Console.WriteLine(membre.Nom);

        List<ResponsableDvp> responsableDvp = new List<ResponsableDvp>();
        responsableDvp.Add(new ResponsableDvp() { Nom = "Louis-Guillaume Morand" });
        responsableDvp.Add(new ResponsableDvp() { Nom = "Jérôme Lambert" });
        responsableDvp.Add(new ResponsableDvp() { Nom = "Stéphane Eyskens" });
        responsableDvp.Add(new ResponsableDvp() { Nom = "Ricky81" });
        responsableDvp.Add(new ResponsableDvp() { Nom = "Fleur-Anne Blain" });

        responsableDvp.Sort(comparer);

        Console.WriteLine();
        Console.WriteLine("Tri des responsables Dvp");
        Console.WriteLine("************************");
        foreach (var membre in responsableDvp)
            Console.WriteLine(membre.Nom);

        Console.Read();
    }
}

Et le résultat :

Il est tout à fait possible d'avoir un type générique qui autorise les modificateurs « out » et « in » en même temps. Prenons l'exemple du délégué « Func » qui propose la signature suivante :

public delegate TResult Func<T, TResult>(T arg)

Ici « T » est un paramètre d'entrée et « TResult » le paramètre de sortie. Ça vous rappelle quelque chose ?! Paramètre de sortie, donc utilisation de « out », paramètre d'entrée, utilisation de « in ». Ce qui donnerait comme signature :

public delegate TResult Func<in T, out TResult>(T arg)

Ainsi pour une même expression lambda, on pourrait utiliser les déclarations de délégués suivantes :

Func<object, string> func1 = s => s.ToString();
Func<string, object> func2 = s => s.ToString();